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