Yes, the main difference in our proposals is primarily one of timing. You're proposing that we have Koha 4.0 ready in about 1 year, and will include Solr integration and updated Perl coding practices. Those are certainly good things, yes, and they may well be possible in 1 year. Or they may not. well, considering Solr is in production at 3 of our libraries, that some
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 12/09/2011 15:37, Ian Walls a écrit : ppl are already involved in reintroducing zebra over the updated API we've developped for Solr, I think it's possible in 1 year. And BibLibre is willing to dedicate the needed ressources to achieve this goal !
I agree that we should continue to do time-based releases; every 6 months seems to be working well for us. The difficulty here, though, is that with time-based releases, you cannot guarantee that any given feature will be ready in time. Sure, any one development team can promise they'll have it coded up to their clients standards and rebased for inclusion, but how will that interact with other code written by other teams? Who, outside the original development team, can be committed to test and sign-off on the work? I don't say it will be easy. But not harder than what had been done before. (Note for newbies : i'm an always optimistic man ;-) ) I add that more coordination will result in less conflicts. And my application is coordination-centric.
So, when working on time-based releases, you cannot promise features. agreed This is why I propose we continue with time-based releases on the 3.X line until such time as all the agreed-upon features for Koha 4.0 are ready. If we're quick, sure, we can jump straight from 3.8 to 4.0. I think it's much more likely we'll have a 3.10 in there, but maybe that's just me. isn't it just a numbering difference ? I feel it is. I've nothing about updating the 1st digit on each major structural change. So, i've nothing against saying something like : "the final goal : solr/persistency/DB abstraction/supporting more than MARC oct 12, Solr & DB abstraction ready = Koha 4.0 april 13, persistency ready = Koha 5.0 oct 13, supporting more than MARC = Koha 6.0
It's just a numbering question, very minor difference ;-)
I think it's more important to define our goals in those terms, rather than in how we're going to accomplish them. Agreed
HDL pointed out early in the thread that some of the features I was floating as possible for Koha 4.0 were librarian-centric, and some were developer-centric. He's right, I wasn't really clearly differentiating in that list. It was mostly meant as an example of what else would could reasonably accomplish for the next major release of the software. Agreed, and coordination (Hackfest in 4 weeks++ on this matter !)
I don't think there will be nearly as many merge conflicts and rebase issues as you fear, Paul. Once we decide on our feature set, any interested developers would meet to figure out the coding requirements. This may take several meetings, but in the end, we'll have a roadmap of what features depend on what. Agreed. I really like the idea of having multiple sandboxes set up so that folks can test the different features more easily. We should definitely do this. Having more people doing testing and Quality Assurance is always a good thing. Providing test plans, test results and reasons for passing/failing QA on the bug report will make it much easier to keep track of the history of any particular fix or feature. BibLibre has now a "private cloud", with 4 servers, virtualization, template VMs. We can easily add physical servers, have a centralised authentification,... Still to be discussed with all of us, but we could add a (physical) server (16GB, quadri code) dedicated to sandboxes (or add VMs the physical server we already use for testing). We will discuss details later.
Our end goal is the same: make Koha the best it can be. We're mostly disagreeing over small details. Whatever the outcome of this discussion, I know we will all continue to work hard together to improve Koha. Agreed ;-)
Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOjBA3AAoJEK81SonuhyGofA4IALE+fszcuU4fqkJWh6pFoBIi zowZwPnElz68LXyAfMLzS2USkvD2sYJ4CYSw3QjgLE0oLMMyvVAobi7wvPLo/u7y S8IL8E/c7ZYeSzoQDI600MzNWt+FrpCQlcuwryxNjCPy8MyNuV/Q4aeei+/Qyj7S TVusfwKf8zaaNeoDMZC8xFj00Ij240pCCoIk0dadVtmINTtGOkmuTYpHOd+Fz4Pb GFDGfss8M70gZwEr8f/bo7kj4b0r+LHxv6xvtz+LR1iPd+f7OL7iikhnnRgSerPI vniy6oImc3sMR6oQGBcOaOhkWVochJMUs4iXRWkwCM3tSyjIWxvSYGFOoxquLiM= =9GlW -----END PGP SIGNATURE-----