-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 12/09/2011 15:37, Ian Walls a écrit : > 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 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----- _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
