[Mageia-dev] Release cycles proposals, and discussion

Sun Jun 19 05:49:22 CEST 2011

Michael Scherer a écrit :
+>
+> 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.
+
+I suspected that it might have been Fedora, if it wasn't a summary of the new mozilla process, but 
+I couldn't remember.  Just the concept intrigued me.  Which I reflected on for a few weeks.
+
+>> 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 ).
+
+I wouldn't quite put it that way ...
+
+>>> 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 ?
+
+great :)
+
+> 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.
+
+That was my assumption : resources fixed in terms of time spent.
+And why would that divide a contributor's focus more than now ?  They would just have a choice.
+Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to 
+contribute to pre-release bugfix, is not contributing.
+So in practice, we risk to have more time contributed during the freeze.
+
+> 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 wasn't assumed.  Rather that as much time would be spent on bug fixes, etc. in pre-release. 
+But having a longer freeze period would likely result in better quality, and certainly less rush.
+
+> 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 ?
+
+Not really.  Being my basic assumption :)
+
+> 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.
+
+As I assumed :)
+
+> 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.
+
+I really don't follow this line of reasoning.
+The focus on bug fixes starts with the freeze.  So a longer freeze would give more time to focus on 
+bug fixes.
+Sure, there are updates and bug fixes in cauldron before the freeze, as a normal part of any 
+development process.  (Even in the non-libre world.)
+
+> 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.
+
+Ok.  Obviously I need to clarify my point of view.
+Firstly, my assumption was that at least as much time would be spent on bug fixing during the 
+longer freeze, but being less rushed, would tend to produce better quality results.  (And less 
+aggravation for ennael)  (That is certainly how it works in the non-libre world.)
+
+I don't see how having the choice between contributing to pre-release or cauldron during the freeze 
+will lead to us loosing _any_ contributors.
+
+As well, since cauldron would be out of freeze virtually all the time, there would be (virtually) 
+no period where contributions to cauldron are blocked.
+Packager time is not an ubiquitous resource.  Some packagers are perl experts, other python, etc. 
+Each packager is more familiar with some packages than others.  Some packagers are excellent 
+developers; others are challenged by basic scripts.  There is a wide range of skills and interests.
+
+If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release 
+for a package with which s/he is not familiar, or contributing to cauldron for something with which 
+s/he is familiar, it would be evidently more efficient to contribute to cauldron.
+
+Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists 
+in cauldron for which the same bug fix must be applied, it is more efficient to apply the same 
+patch right away, than to wait until freeze is over.  (Personnally I've encountered this sort of 
+situation with similar but different software many times.  Any experienced programmer should 
+understand this point.)
+
+So there are a lot of (admittedly small) synergies which should lead to packager time being more 
+efficiently used.
+Not counting the likelyhood that some packagers would contribute somewhat more time, being able to 
+contribute to cauldron during freeze.
+The major benefit in my mind is the longer freeze period.
+
+How much this would help, I don't know.  But I think it is worth a try.
+(Even if we end up going for a 9-month release cycle, instead of my preferred 6 months.)
+
+>
+>>> - 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.
+
+ok :)
+
+>>> 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.
+
+We may not be farm animals, but I suspect that we are still creatures of habit :)
+In any case, it seems to me that the bigger liability would be being out of sync with the 6-month 
+release cycle of kde, gnome, as well as many other distros.
+
+another 2 cents :)
+
+-- 
+André
+