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

[Paul Poulain]

Le 21/06/2010 22:04, Chris Nighswonger a écrit :
> 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.
>   
I never wrote that publicly, but I must say i'm not very proud of the
new acq code. it can/must be improved a lot.
> 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.
>   
of course. the idea being that merging very early (reminder : everything
is written) means we would have 6 months to find & fix bugs. It's not
the same as merging 10 days before releasing imo.
>> 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.
>   
agreed. The problem being that 3.2 is very late. Today, we have to do
something to merge our work.
> I would suggest that the problem is not with the feature freeze, but
> perhaps with not keeping in sync with the main repo master.
>   
we tried, but had some bugs introduced by the merge + we were too short
on time.
Again : today, we (BibLibre) are willing to do something because in a
few weeks, it'll be too late, unfortunately
>
> 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.
>   
see answer to the other chris for the rest of your mail ;-)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08