diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005832.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005832.html | 283 |
1 files changed, 283 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005832.html b/zarb-ml/mageia-dev/2011-June/005832.html new file mode 100644 index 000000000..efb139f74 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005832.html @@ -0,0 +1,283 @@ +<!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=%3C4DFD71C2.9050000%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005824.html"> + <LINK REL="Next" HREF="005840.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Release cycles proposals, and discussion</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Release%20cycles%20proposals%2C%20and%20discussion&In-Reply-To=%3C4DFD71C2.9050000%40laposte.net%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">andr55 at laposte.net + </A><BR> + <I>Sun Jun 19 05:49:22 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005824.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005840.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5832">[ date ]</a> + <a href="thread.html#5832">[ thread ]</a> + <a href="subject.html#5832">[ subject ]</a> + <a href="author.html#5832">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael Scherer a écrit : +><i> +</I>><i> Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : +</I>>><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>><i> +</I>><i> you can say the name of the project, even if I suspect it to be Fedora. +</I> +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. + +>><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>><i> +</I>><i> So you suggest that in order to help packagers focusing on bug fixing, +</I>><i> that we have them take care of cauldron and the bugfixes for the stable +</I>><i> release ( ie, twice more the load ). +</I> +I wouldn't quite put it that way ... + +>>><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>><i> +</I>><i> Let's do some math, shall we ? +</I> +great :) + +><i> If people work the same amount of time, with work divided on 2 products, +</I>><i> they must share their time, and usually work less than if they focused +</I>><i> only on one product, unless there is twice the ressources. But I doubt +</I>><i> this will happen for us, so let's assume that ressources are fixed. +</I> +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. + +><i> Let say : +</I>><i> - the freeze period is Y weeks, +</I>><i> - the time between 2 release is X weeks, +</I>><i> - people divide their time evenly on both products. +</I> +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. + +><i> That's a simplification, but I will come back on that later. Let's also +</I>><i> count the time spent as the metrics for the work, even if man/month is a +</I>><i> wrong unit in software development ( but that's a good enough +</I>><i> approximation for our case, given the highly distributed and +</I>><i> decentralized nature of the work of releasing a distribution ). +</I>><i> +</I>><i> So when there is the freeze ( at release(n) time - Y weeks ), we will +</I>><i> have Y weeks of work done on both products ( next release, and cauldron +</I>><i> ), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out +</I>><i> ( before the next freeze for release(n+1) ), and then again Y/2 weeks. +</I>><i> +</I>><i> So for the release (n+1), we spend : +</I>><i> Y/2 + X - Y + Y/2 +</I>><i> = 2 * Y/2 - Y + X +</I>><i> = Y - Y + X +</I>><i> = X +</I>><i> +</I>><i> So that give X weeks of work. Fascinating, isn't it ? +</I> +Not really. Being my basic assumption :) + +><i> Now, of course, we can say "what if people do not divide their work in +</I>><i> 2 ?" +</I>><i> +</I>><i> So let's call : +</I>><i> - F the time spent on bugfix during the freeze +</I>><i> - C the time spent on cauldron during the freeze +</I>><i> +</I>><i> We can assume that : +</I>><i> C + F = Y +</I>><i> +</I>><i> So the equation become : +</I>><i> C + ( X - Y ) + F +</I>><i> = C + F - Y + X +</I>><i> = X +</I>><i> +</I>><i> So no matter how you divide the time, you still have the same amount of +</I>><i> time spent overall. +</I> +As I assumed :) + +><i> Now, the real important question is "can we really exchange work done as +</I>><i> part of C for work done as part of F". +</I>><i> +</I>><i> And so "if I do regular packages updates on cauldron at the begining of +</I>><i> the cycle, does it count as bugfixing for the release in the end of the +</I>><i> cycle" ? +</I>><i> +</I>><i> To me, the answer is clearly no. If it was somethig we could exchange, +</I>><i> we would not have to make a freeze in the first place to make sure that +</I>><i> only bugfixes are uploaded in cauldron. +</I>><i> +</I>><i> So the only way to maximize the time spent on bugfixes is to have F = Y, +</I>><i> and so C = 0. Ie, do like we do now. +</I> +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.) + +><i> And unless you show that letting people work on cauldron will bring more +</I>><i> ressources , and more than the one we will lose du to people who do not +</I>><i> want to work on bugfixes and the release, I doubt this will change. +</I> +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.) + +><i> +</I>>>><i> - short life cycle +</I>>><i> would be alleviated by having periodic long term support releases (lasting at least 2 years). +</I>><i> +</I>><i> As said before, the support is decided in another discussion, and depend +</I>><i> more on the ressources we will have than anything else. +</I> +ok :) + +>>><i> Proposal 2 +</I>>>><i> ---------------- +</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> +</I>><i> I do not expect our users to be farm animals, so they can perfectly cope +</I>><i> with lack of seasonal hints regarding release cycle. +</I> +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é +</PRE> + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005824.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005840.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5832">[ date ]</a> + <a href="thread.html#5832">[ thread ]</a> + <a href="subject.html#5832">[ subject ]</a> + <a href="author.html#5832">[ 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> |