[Koha-devel] About Release process

[Fischer, Katrin]

Hi all, 

I am also worried about this. I agree with Owen and Marcel. 

Who will be testing and who will be fixing bugs? I think the problem will only get moved a bit in time, but it will still be there. Both branches will diverge quickly as soon as patches are only pushed to one of them. Then we will start to need different patches for bug fixes, patches will not apply, testers will have to test on each branch separately etc.  
And if we decide to only push bug fixes to both branches at once, where is the benefit of having 2 branches?
We already have problems with testing - why make this even harder?

I am also not persuaded moving the release date is a good idea, because we switched to time based releases for having reliable release dates and being able to plan. I also fear by moving it to November, we will move it right into the "end of year madness". Also we will maybe have the same problem again with a RM from a different country/continent. So if we decide to move the dates, please let us stick to those forever.

Katrin


-----Ursprüngliche Nachricht-----
Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Marcel de Rooy
Gesendet: Do 19.07.2012 10:48
An: koha-devel at lists.koha-community.org
Betreff: Re: [Koha-devel] About Release process
 
Hi,
I do have [some] doubts too on this double master-approach.
If there is a feature-frozen old-master 3.9 branch and a new master 3.11 branch, where will most developers be spending their time? Will they be bug-fixing in 3.9 or rather go to 3.11 and send new patches? If new master has the most attraction, this move will not really work (who is testing?). If most people would stick to old master, why start new master in the first place? I just fear that many will go to new master..
Bugs fixed in 3.9 should go up to 3.11; this will be an additional effort. (Small side note: When patches are going up and down, workflow needs to be adjusted?)

So, whatever we do, probably this old problem will always be there.. Much depends on the RM, and better testing :)

Marcel


Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Jared Camins-Esakov
Verzonden: woensdag 18 juli 2012 18:51
Aan: Owen Leonard
CC: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] About Release process

Owen,
>     - branch the release on git. master goes his way for N+1, major ENH
> can be pushed here. N is still controlled by the RM, N-1 controlled by
> the RMaint
I'm not sure I understand this aspect of it. The branching is to allow
enhancements to still be pushed somewhere while what-was-master is in
feature freeze? I would think there is some benefit of not pushing any
enhancements *anywhere* to encourage folks to be bug-fixing instead.

That is correct. As RM presumptive (but perhaps someone else would like to be RM, and eliminate my presumptive status? There's still time :D ), my plan for this period would be to push any enhancements that might be submitted only after bugfixes have been dealt with. Ideally it will be possible to get all submitted enhancements pushed to Master during this period, but given the volume of patches that can precede a release, at my discretion I may delay large features until after the release of 3.10.0.

Paul and I discussed this at length, actually. I originally suggested not pushing any large enhancements to master (i.e. 3.11) during the 3.10 feature freeze, but Paul (quite reasonably, I think) argued that not pushing enhancements that were sitting in the queue would not serve to get those developers working on bugfixes, but rather just result in a heavier burden on the RM for 3.12 once 3.10.0 was released. As a compromise, any enhancements that can be pushed will be, but anything that gets in the way of the more important bug fixing will not be pushed until 3.10.0 has left the nest.

Hope this clarifies.

Regards,
Jared

--
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com<mailto:jcamins at cpbibliography.com>
(web) http://www.cpbibliography.com/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120719/1fc44b10/attachment.htm>