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

[Chris Nighswonger]

Hi Paul,

2010/6/21 Paul Poulain <paul.poulain at biblibre.com>:
> 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

Ouch!

>
> So : if we do nothing, in a few *weeks*, we will have a fork that we
> want to avoid !

Great!

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

I think, this would be the place to implement the first of Chris'
suggestions: Have hdl (or whoever) do this merging in such a way as to
produce smaller feature-centric branches. (Think "bite sized" pieces.)
However, I think this must be done concurrent to development on 3.4.

We must also consider that if we are ever to have schedule based
releases, we *must* take this opportunity to hold on to a stable
master and use branching along with merging to facilitate ongoing
development while maintaining that stable master. So here is a good
place to begin.

As BibLibre finishes up merging on a particular feature branch, QA can
immediately pickup with testing and then the RM take care of merging
the tested branch into master, thus keeping master stable.

I think if everyone pitches in that this could all happen in a month
time frame. As you say, these new features are in production on
several of your large clients, so they should not be too buggy.

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

As Chris and Nicole have pointed out, I don't think a direct push into
a stable master of this large of a patch set will prove beneficial to
anyone.

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

The rest of this naturally follows along of course. We need some
enforcement of rules especially as the project gets bigger and larger
support companies are pushing the development at a greater pace. It
will be especially imperative that those who have the resources to
push development faster adhere more strictly to good
coding/testing/etc practices as messy code in large quantities will
quickly produce chaos and be of little use in the long haul.

Kudos to BbLibre for being open and transparent in all of this and for
requesting community input as they undergo growing pains.

Kind Regards,
Chris