diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2011-June/005824.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip | |
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005824.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005824.html | 221 |
1 files changed, 221 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005824.html b/zarb-ml/mageia-dev/2011-June/005824.html new file mode 100644 index 000000000..011cc2482 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005824.html @@ -0,0 +1,221 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Release cycles proposals, and discussion + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Release%20cycles%20proposals%2C%20and%20discussion&In-Reply-To=%3C1308415907.11316.157.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005809.html"> + <LINK REL="Next" HREF="005832.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Release cycles proposals, and discussion</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Release%20cycles%20proposals%2C%20and%20discussion&In-Reply-To=%3C1308415907.11316.157.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">misc at zarb.org + </A><BR> + <I>Sat Jun 18 18:51:46 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005809.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005832.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5824">[ date ]</a> + <a href="thread.html#5824">[ thread ]</a> + <a href="subject.html#5824">[ subject ]</a> + <a href="author.html#5824">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : +><i> Michael Scherer a écrit : +</I>><i> +</I>><i> > Proposal 1: +</I>><i> > 6 months release cycle -> 12 months life cycle +</I>><i> > ( Fedora, Ubuntu, Mandriva< 2010.1&& Mandriva != 2006.0 ) +</I>><i> > +</I>><i> > Proposal 2: +</I>><i> > 9 months release cycle -> 18 months life cycle +</I>><i> > ( ~ opensuse and the one we used for Mageia 1 ) +</I>><i> > +</I>><i> > Proposal 3: +</I>><i> > 12 months release cycle -> 24 months life cycle +</I>><i> > ( Mandriva> 2010.1 ) +</I>><i> +</I>><i> +</I>><i> First, suggest an amended freeze process (idea from recent report of another project) +</I> +you can say the name of the project, even if I suspect it to be Fedora. + +><i> Instead of a freeze on cauldron until everything is ready for the release, we do +</I>><i> 1) short freeze on cauldron +</I>><i> 2) copy cauldron to pre-release branch, which remains frozen until release +</I>><i> 3) immediately unfreeze cauldron. +</I>><i> +</I>><i> - we avoid blocking cauldron, while leaving pre-release frozen for bug fixes. +</I>><i> - updates can continue on cauldron. Bugfixes can be applied to newer versions, if present in +</I>><i> cauldron, at the same time as corresponding bugfixes in pre-release. +</I>><i> - activities like translation can continue in cauldron, meaning less rush for such updates. +</I>><i> - because cauldron is open to changes (virtually) all the time, they don't have to be put off and +</I>><i> perhaps forgotten. +</I>><i> - the cauldron cycle is extented by the time of the pre-release freeze. e.g. In a release cycle of +</I>><i> 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months. +</I>><i> This allows more time to iron out the pre-release bugs and more time for cauldron. +</I>><i> - with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what +</I>><i> is accepted during freeze. (Certain more recent packages or translations, for example.) +</I>><i> - note that we would still have to monitor cauldron to avoid freezing partially implemented complex +</I>><i> changes, such as a major update of kde or gnome or perl, etc. But we have to do that now, anyway. +</I> +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> +</I>><i> > Proposal 1 : +</I>><i> > --------------- +</I>><i> My personal preference +</I>><i> +</I>><i> > Pros: +</I>><i> > - better hardware support +</I>><i> > - up to date versions / upstream projects (must have for developers) +</I>><i> - coincides with kde/gnome releases +</I>><i> +</I>><i> - amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron +</I>><i> development time. +</I>><i> A 1-month pre-release freeze would add 1 month to cauldron development time. +</I>><i> This would tend to alleviate the rush of the 6-month release cycle. +</I> +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. + +><i> > - short life cycle +</I>><i> would be alleviated by having periodic long term support releases (lasting at least 2 years). +</I> +As said before, the support is decided in another discussion, and depend +more on the ressources we will have than anything else. + +><i> +</I>><i> > Proposal 2 +</I>><i> > ---------------- +</I> +><i> > Cons: +</I>><i> > - not synchronized with gnome or others that use a 6 month cycle +</I>><i> > - potentially release when there isn't much activity (like during Holidays) +</I>><i> - release would not be the same month every year +</I>><i> e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ... +</I>><i> so users won't know when to expect a release +</I> +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 + +</PRE> + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005809.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005832.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5824">[ date ]</a> + <a href="thread.html#5824">[ thread ]</a> + <a href="subject.html#5824">[ subject ]</a> + <a href="author.html#5824">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |