[Mageia-dev] Release cycles proposals, and discussion

Sat Jun 18 18:51:46 CEST 2011

Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> 
+> > Proposal 1:
+> > 6 months release cycle ->  12 months life cycle
+> > ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
+> >
+> > Proposal 2:
+> > 9 months release cycle ->  18 months life cycle
+> > ( ~ opensuse and the one we used for Mageia 1 )
+> >
+> > Proposal 3:
+> > 12 months release cycle ->  24 months life cycle
+> > ( Mandriva>  2010.1 )
+> 
+> 
+> First, suggest an amended freeze process (idea from recent report of another project)
+
+you can say the name of the project, even if I suspect it to be Fedora.
+
+> Instead of a freeze on cauldron until everything is ready for the release, we do
+> 1) short freeze on cauldron
+> 2) copy cauldron to pre-release branch, which remains frozen until release
+> 3) immediately unfreeze cauldron.
+> 
+> - we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
+> - updates can continue on cauldron.  Bugfixes can be applied to newer versions, if present in 
+> cauldron, at the same time as corresponding bugfixes in pre-release.
+> - activities like translation can continue in cauldron, meaning less rush for such updates.
+> - because cauldron is open to changes (virtually) all the time, they don't have to be put off and 
+> perhaps forgotten.
+> - the cauldron cycle is extented by the time of the pre-release freeze.  e.g. In a release cycle of 
+> 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months.
+> This allows more time to iron out the pre-release bugs and more time for cauldron.
+> - with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what 
+> is accepted during freeze.  (Certain more recent packages or translations, for example.)
+> - note that we would still have to monitor cauldron to avoid freezing partially implemented complex 
+> changes, such as a major update of kde or gnome or perl, etc.  But we have to do that now, anyway.
+
+So you suggest that in order to help packagers focusing on bug fixing,
+that we have them take care of cauldron and the bugfixes for the stable
+release ( ie, twice more the load ).
+
+> 
+> > Proposal 1 :
+> > ---------------
+> My personal preference
+> 
+> > Pros:
+> > - better hardware support
+> > - up to date versions / upstream projects (must have for developers)
+> - coincides with kde/gnome releases
+>
+> - amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron 
+> development time.
+> A 1-month pre-release freeze would add 1 month to cauldron development time.
+> This would tend to alleviate the rush of the 6-month release cycle.
+
+Let's do some math, shall we ?
+
+If people work the same amount of time, with work divided on 2 products,
+they must share their time, and usually work less than if they focused
+only on one product, unless there is twice the ressources. But I doubt
+this will happen for us, so let's assume that ressources are fixed. 
+
+Let say : 
+- the freeze period is Y weeks, 
+- the time between 2 release is X weeks, 
+- people divide their time evenly on both products. 
+
+That's a simplification, but I will come back on that later. Let's also
+count the time spent as the metrics for the work, even if man/month is a
+wrong unit in software development ( but that's a good enough
+approximation for our case, given the highly distributed and
+decentralized nature of the work of releasing a distribution ).
+
+So when there is the freeze ( at release(n) time - Y weeks ), we will
+have Y weeks of work done on both products ( next release, and cauldron
+), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
+( before the next freeze for release(n+1) ), and then again Y/2 weeks.
+
+So for the release (n+1), we spend : 
+Y/2 + X - Y + Y/2 
+= 2 * Y/2 - Y + X  
+= Y - Y + X
+= X
+
+So that give X weeks of work. Fascinating, isn't it ?
+Now, of course, we can say "what if people do not divide their work in
+2 ?" 
+
+So let's call :
+- F the time spent on bugfix during the freeze
+- C the time spent on cauldron during the freeze
+
+We can assume that :
+C + F = Y 
+
+So the equation become :
+C + ( X - Y ) + F 
+= C + F - Y + X 
+= X 
+
+So no matter how you divide the time, you still have the same amount of
+time spent overall. 
+
+Now, the real important question is "can we really exchange work done as
+part of C for work done as part of F". 
+
+And so "if I do regular packages updates on cauldron at the begining of
+the cycle, does it count as bugfixing for the release in the end of the
+cycle" ? 
+
+To me, the answer is clearly no. If it was somethig we could exchange,
+we would not have to make a freeze in the first place to make sure that
+only bugfixes are uploaded in cauldron.
+
+So the only way to maximize the time spent on bugfixes is to have F = Y,
+and so C = 0. Ie, do like we do now.
+
+And unless you show that letting people work on cauldron will bring more
+ressources , and more than the one we will lose du to people who do not
+want to work on bugfixes and the release, I doubt this will change.
+
+> > - short life cycle
+> would be alleviated by having periodic long term support releases (lasting at least 2 years).
+
+As said before, the support is decided in another discussion, and depend
+more on the ressources we will have than anything else. 
+
+> 
+> > Proposal 2
+> > ----------------
+
+> > Cons:
+> > - not synchronized with gnome or others that use a 6 month cycle
+> > - potentially release when there isn't much activity (like during Holidays)
+> - release would not be the same month every year
+> e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ...
+> so users won't know when to expect a release
+
+I do not expect our users to be farm animals, so they can perfectly cope
+with lack of seasonal hints regarding release cycle. 
+
+-- 
+Michael Scherer
+
+