diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005840.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005840.html | 290 |
1 files changed, 290 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005840.html b/zarb-ml/mageia-dev/2011-June/005840.html new file mode 100644 index 000000000..496f30c1c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005840.html @@ -0,0 +1,290 @@ +<!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=%3C4DFDD21D.3010505%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005832.html"> + <LINK REL="Next" HREF="005841.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=%3C4DFDD21D.3010505%40laposte.net%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">andr55 at laposte.net + </A><BR> + <I>Sun Jun 19 12:40:29 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005832.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005841.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5840">[ date ]</a> + <a href="thread.html#5840">[ thread ]</a> + <a href="subject.html#5840">[ subject ]</a> + <a href="author.html#5840">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>andre999 a écrit : +><i> Michael Scherer a écrit : +</I>>><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 +</I>>>><i> another project) +</I>>><i> +</I>>><i> you can say the name of the project, even if I suspect it to be Fedora. +</I>><i> +</I>><i> I suspected that it might have been Fedora, if it wasn't a summary of +</I>><i> the new mozilla process, but I couldn't remember. Just the concept +</I>><i> intrigued me. Which I reflected on for a few weeks. +</I>><i> +</I>>>><i> Instead of a freeze on cauldron until everything is ready for the +</I>>>><i> release, we do +</I>>>><i> 1) short freeze on cauldron +</I>>>><i> 2) copy cauldron to pre-release branch, which remains frozen until +</I>>>><i> release +</I>>>><i> 3) immediately unfreeze cauldron. +</I>>>><i> +</I>>>><i> - we avoid blocking cauldron, while leaving pre-release frozen for +</I>>>><i> bug fixes. +</I>>>><i> - updates can continue on cauldron. Bugfixes can be applied to newer +</I>>>><i> 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 +</I>>>><i> rush for such updates. +</I>>>><i> - because cauldron is open to changes (virtually) all the time, they +</I>>>><i> 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 +</I>>>><i> freeze. e.g. In a release cycle of +</I>>>><i> 6 months and a pre-release freeze of 1 month, the cauldron cycle +</I>>>><i> would be 7 months. +</I>>>><i> This allows more time to iron out the pre-release bugs and more time +</I>>>><i> for cauldron. +</I>>>><i> - with the longer pre-release freeze, it may be appropriate to modify +</I>>>><i> somewhat the policy on what +</I>>>><i> is accepted during freeze. (Certain more recent packages or +</I>>>><i> translations, for example.) +</I>>>><i> - note that we would still have to monitor cauldron to avoid freezing +</I>>>><i> partially implemented complex +</I>>>><i> changes, such as a major update of kde or gnome or perl, etc. But we +</I>>>><i> 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> +</I>><i> I wouldn't quite put it that way ... +</I>><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 +</I>>>><i> pre-release freeze time and cauldron +</I>>>><i> development time. +</I>>>><i> A 1-month pre-release freeze would add 1 month to cauldron +</I>>>><i> 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>><i> +</I>><i> great :) +</I>><i> +</I>>><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>><i> +</I>><i> That was my assumption : resources fixed in terms of time spent. +</I>><i> And why would that divide a contributor's focus more than now ? They +</I>><i> would just have a choice. +</I>><i> Now during the freeze, someone that wants to contribute to cauldron, but +</I>><i> can't or chooses not to contribute to pre-release bugfix, is not +</I>><i> contributing. +</I>><i> So in practice, we risk to have more time contributed during the freeze. +</I>><i> +</I>>><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>><i> +</I>><i> That wasn't assumed. Rather that as much time would be spent on bug +</I>><i> fixes, etc. in pre-release. But having a longer freeze period would +</I>><i> likely result in better quality, and certainly less rush. +</I>><i> +</I>>><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>><i> +</I>><i> Not really. Being my basic assumption :) +</I>><i> +</I>>><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>><i> +</I>><i> As I assumed :) +</I>><i> +</I>>><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> +</I>><i> I really don't follow this line of reasoning. +</I>><i> The focus on bug fixes starts with the freeze. So a longer freeze would +</I>><i> give more time to focus on bug fixes. +</I>><i> Sure, there are updates and bug fixes in cauldron before the freeze, as +</I>><i> a normal part of any development process. (Even in the non-libre world.) +</I>><i> +</I>>><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>><i> +</I>><i> Ok. Obviously I need to clarify my point of view. +</I>><i> Firstly, my assumption was that at least as much time would be spent on +</I>><i> bug fixing during the longer freeze, but being less rushed, would tend +</I>><i> to produce better quality results. (And less aggravation for ennael) +</I>><i> (That is certainly how it works in the non-libre world.) +</I>><i> +</I>><i> I don't see how having the choice between contributing to pre-release or +</I>><i> cauldron during the freeze will lead to us loosing _any_ contributors. +</I>><i> +</I>><i> As well, since cauldron would be out of freeze virtually all the time, +</I>><i> there would be (virtually) no period where contributions to cauldron are +</I>><i> blocked. +</I>><i> Packager time is not an ubiquitous resource. Some packagers are perl +</I>><i> experts, other python, etc. Each packager is more familiar with some +</I>><i> packages than others. Some packagers are excellent developers; others +</I>><i> are challenged by basic scripts. There is a wide range of skills and +</I>><i> interests. +</I>><i> +</I>><i> If during freeze, a packager has a choice between attempting to help +</I>><i> with a bugfix in pre-release for a package with which s/he is not +</I>><i> familiar, or contributing to cauldron for something with which s/he is +</I>><i> familiar, it would be evidently more efficient to contribute to cauldron. +</I>><i> +</I>><i> Similarly, if a packager contributes a bug fix to pre-release, and a +</I>><i> newer package already exists in cauldron for which the same bug fix must +</I>><i> be applied, it is more efficient to apply the same patch right away, +</I>><i> than to wait until freeze is over. (Personnally I've encountered this +</I>><i> sort of situation with similar but different software many times. Any +</I>><i> experienced programmer should understand this point.) +</I>><i> +</I>><i> So there are a lot of (admittedly small) synergies which should lead to +</I>><i> packager time being more efficiently used. +</I>><i> Not counting the likelyhood that some packagers would contribute +</I>><i> somewhat more time, being able to contribute to cauldron during freeze. +</I>><i> The major benefit in my mind is the longer freeze period. +</I>><i> +</I>><i> How much this would help, I don't know. But I think it is worth a try. +</I>><i> (Even if we end up going for a 9-month release cycle, instead of my +</I>><i> preferred 6 months.) +</I>><i> +</I> +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é +</PRE> + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005832.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005841.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5840">[ date ]</a> + <a href="thread.html#5840">[ thread ]</a> + <a href="subject.html#5840">[ subject ]</a> + <a href="author.html#5840">[ 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> |