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

[Chris Nighswonger]

On Mon, Jun 21, 2010 at 3:40 PM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Le 21/06/2010 20:44, Chris Cormack a écrit :
>> 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.
> 1- we did a lot of QA on them, and although there may be some remaining
> bugs, we are live with them on 1 site, very soon on a second one, and
> many more.

But this approach is not acceptable in the community at large as
evidenced by the BibLibre acquisitions work introducing four blockers.
What you and your clients may be able to live with, others may not be
able to live with. So not only do we need good QA at the vendor level,
but also at the community level as well.

> 2- we proposed to submit those patches many months ago, but galen
> decision was : "feature freeze for 3.2". We had to go ahead.

This had to happen some time.

I would suggest that the problem is not with the feature freeze, but
perhaps with not keeping in sync with the main repo master.

> 3- we will deal with any problem that may arise. And if 3.4 has to be
> released in something like 6 months, that's enough, undoubtfully

I think there is a better way. One which requires less resources on
the part of one company. I cannot imagine agreeing to take on every
possible problem that may arise from the merging of 400+ patches into
a branch that is already 100 patches behind. I would not expect any
company to take that upon themselves when we can do it in a much
cleaner manner.

> 4- splitting them in smaller feature set is a more than huge work. It's
> probably almost impossible.

I think that at a minimum the present BibLIbre work would need to be
merged into a topic branch off of the stable 3.2 master and then
testing/debugging be done on that topic branch while keeping it in
sync with the stable master.

In no case does it appear that applying 400+ patches to a stable
master would be possible. *That* would make for huge work.

>
> So, even if your proposition is a good idea, I think it's not a possible
> way to go for us. You're reaching our (BibLibre) limit. So, if someone
> is volunteering for this more-than-huge job, then, fair, head to
> git.biblibre.com/master, it's here, available, all commits comments are
> in english. But you can't count on us to do that, even if I'm sorry, really.

My only observation here would be that the burden of keeping
development work in sync with the official HEAD *must* always fall
primarily on the developer and not the community. This is a relatively
easy task seeing we are using git version control and not svn or some
other less friendly sort.

Again, I think the new features are great. Its the logistics that are
the fly in the ointment so to speak.

Kind Regards,
Chris