[Koha-devel] Commentary on Paul's Koha 3.8 Release Manager proposal

[Paul Poulain]

-----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-----