[Koha-devel] BibLibre strategy for Koha 3.4 and next versions

[Chris Cormack]

2010/6/22 Paul Poulain <paul.poulain at biblibre.com>:
> Le 02/06/2010 10:25, Chris Cormack a écrit :
>
>> So as RM I accept the challenge of faster releases, and throw back a
>> challenge of better patches :)
>
>
> Chris & al,
>
> We (BibLibre & the community) face a big problem, and we must deal with
> it here and now : we (BibLibre) are deploying biblibre/master. It's live
> in Lyon3 university, it'll be live in Nimes next weeks, in SAN-OP in a
> few more weeks (migrating from 3.0).
> It contains a lot of new features (circ rules rewritten, and other new
> features described in wiki.koha-community.org, RFC for 3.4 from BibLibre)
>
> And we have a lot of new contracts falling.
>
> The technical fact :
> - we (BibLibre) have 450+ patches on git.biblibre.com, master branch,
> that are not in git.koha-community.org (new features & bugfixes)
> - koha-community has 100 patches that are not on biblibre/master
>
> So : if we do nothing, in a few *weeks*, we will have a fork that we
> want to avoid !
>
> Here is our proposal :
> 1- release 3.2
> 2- we (BibLibre) rebase our master to 3.2 (that's 450+ patches)
> 3- we (BibLibre) submit them to master/koha
> 4- you (chris) push them into main trunk (as they are)
> 5- we (community) define the rules for all the next devs.
> 6- start working with new rules => september
>
> 1-Release 3.2 :
> =============
> hdl will take care this next two weeks of the 2 BLO related to
> updatedatabase & affected to him
>
> 2 - rebase biblibre/master on koha/master
> ==============
> We (BibLibre) take care of rebasing our master at a date we define
> altogether. As that will be a HUGE work, you (chris) don't apply any other
> patches while we rebase to avoid breaking our work. We think we would need
> one week (maybe two) to rebase & test properly.
>
> 3/4 - push biblibre patches on koha/master
> ==============
> You (chris) push our 450+ patches on koha/master. Since the new rules were
> not defined when we wrote all this code, those patches don't abide by those
> rules and can't.
>
> 5 - define rules
> ==============
> Once 3.2 is released, we (community) set all rules (Including coding style,
> test cases, choosing OO pattern, standard commit notes,...) and everybody
> use them - including us (BibLibre) we don't request to be favored -
>
> 6 - work on 3.4
> ==============
> All RFCs we wrote on the wiki are now implemented for our Nimes & Lyon 3
> customers. If something new comes, we will respect fully the new rules.
> There may be some patches fixing Lyon3/Nimes features that won't respect
> them, but, hopefully, there will be only a few of them (Lyon3 is live, Nimes
> go live next week, so it's really stable)
> --

This is certainly a possible plan of action, but no, I won't be
pushing any patches to master without them going through QA.
Certainly not 450 in one go. They will need to be branched into
smaller feature sets and each one tested and merged. What I am willing
to do, is be less strict about accompanying tests as the patches were
written before that, what I am not willing to do is merge 450 patches
that haven't been looked at by QA or the Release Manager into master.
These aren't new rules.
Splitting them up into featuresets will make their integration much faster.

Chris