[Mageia-dev] Release cycles proposals, and discussion

Sun Jun 19 12:40:29 CEST 2011

andre999 a écrit :
+> 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.)
+>
+
+Another thought about the amended freeze process.
+Have you noticed how packagers sometimes set off an exchange of 10 or more emails in attempts to 
+get a package into the release during the freeze ?
+The packager wants to submit, but they can't because cauldron is frozen.  Maybe if only pre-release 
+were frozen, but cauldron open, they would accept submitting to cauldron after only 1 or 2 
+exchanges.  They would have the at least partial satisfaction of being able to submit their package 
+(instead of waiting, and doing something else, probably elsewhere), and others would have been 
+releaved of the hassle of dealing with their repeated requests.
+I think that would be more motivating for the packager in question, as well as the others involved.
+And packagers would avoid wasting both time and energy.
+
+-- 
+André
+