diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005847.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005847.html | 244 |
1 files changed, 244 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005847.html b/zarb-ml/mageia-dev/2011-June/005847.html new file mode 100644 index 000000000..2b32c4931 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005847.html @@ -0,0 +1,244 @@ +<!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=%3C1308493783.11316.269.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="005844.html"> + <LINK REL="Next" HREF="005864.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=%3C1308493783.11316.269.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">misc at zarb.org + </A><BR> + <I>Sun Jun 19 16:29:42 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005844.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005864.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5847">[ date ]</a> + <a href="thread.html#5847">[ thread ]</a> + <a href="subject.html#5847">[ subject ]</a> + <a href="author.html#5847">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le samedi 18 juin 2011 à 23:49 -0400, 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> > 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 ? +</I>><i> They would just have a choice. +</I> +So before, the choice is between : +- not doing anything +- bugfixing + +After your proposal, there is : +- not doing anything +- bugfixing +- uploading new stuff to cauldron + +And you fail to see how it divert focus ? + +><i> Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to +</I>><i> contribute to pre-release bugfix, is not contributing. +</I>><i> So in practice, we risk to have more time contributed during the freeze. +</I> +My own experience tell the contrary, but maybe you should ask to Anne +her opinion if you do not believe me, or to others people who did +distribution releases ( and not software releases, which is slightly +different, mainly because there is less ). + +><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> +No. +"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." + +The cauldron cycle would be 7 months just on the calendar, but 6 months +worth of work, as demonstrated. + +"A 1-month pre-release freeze would add 1 month to cauldron development +time." + +That's the same, you do not add real months, just months on the +calendar. + +><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 give more time to focus on +</I>><i> bug fixes. +</I> +The focus on bugfixing start with version freeze, since what introduce +problem is various changes, and new versions of softwares usually bring +new changes. Then we block all uploads except bug fixes, and then all +uploads unless very serious bug fixes ( ie, release blocker ). So the +focus start much before the last freeze, and you are quite unclear. + +><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 bug fixing during the +</I>><i> longer freeze, but being less rushed, would tend to produce better quality results. (And less +</I>><i> aggravation for ennael) (That is certainly how it works in the non-libre world.) +</I> +You do not say much how you extend the freeze to be longer, nor even +that the freeze appear sooner, reread your mail. Nor what kind of freeze +would it be. + +The only mention of the duration of the freeze is : +"A 1-month pre-release freeze would add 1 month to cauldron development +time." + +The version freeze started on 20 april +( <A HREF="https://mageia.org/pipermail/mageia-dev/20110419/004066.html">https://mageia.org/pipermail/mageia-dev/20110419/004066.html</A> ), which +is more than 1 month. The release freeze was on 14 may, which is 2 +weeks. + +Given that the version freeze is when we start to ask to people to focus +on bugfixes and when we prevent packagers from uploading newer versions +of packages, the proposed 1 month pre-release freeze is unclear and +unexplained. + + +><i> I don't see how having the choice between contributing to pre-release or cauldron during the freeze +</I>><i> will lead to us loosing _any_ contributors. +</I> +We do not lose contributors, we lose the work of people that prefer to +work on cauldron by uploading new versions rather than bug fixing, and +from people that will prefer to test and use cauldron rather than the +future stable release, because that's easier, there is no deadline, nor +any obligation, and there is newer stuff. + + +><i> If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release +</I>><i> for a package with which s/he is not familiar, or contributing to cauldron for something with which +</I>><i> s/he is familiar, it would be evidently more efficient to contribute to cauldron. +</I> +You are placing a wrong dichotomy. The choice is not between "fixing +something efficiently on cauldron vs fixing un-efficiently on +pre-release", but between "fixing un-efficiently" vs "not fixing". + +><i> Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists +</I>><i> in cauldron for which the same bug fix must be applied, it is more efficient to apply the same +</I>><i> patch right away, than to wait until freeze is over. (Personnally I've encountered this sort of +</I>><i> situation with similar but different software many times. Any experienced programmer should +</I>><i> understand this point.) +</I> +With the current process, the fix is already applied for next cauldron +cycle, since the package is the same, there is no branching. + +><i> So there are a lot of (admittedly small) synergies which should lead to packager time being more +</I>><i> efficiently used. +</I>><i> Not counting the likelyhood that some packagers would contribute somewhat more time, being able to +</I>><i> contribute to cauldron during freeze. +</I>><i> The major benefit in my mind is the longer freeze period. +</I> +Which mean that we will have more outdated software if we freeze sooner. + +Assuming that the pre-release freeze you are speaking about is what the +packagers know as "release freeze", this means the version freeze will +be sooner too. Assuming that what you call "pre-release freeze" is the +version freeze, then the freeze period would just be shorter. + +Also, your point seems to forget to take in account that people can +focus on bugfixs without any freeze of the distribution, yet, they do +not seems to do so. + +People rushing packages in the last minute as it always happen is the +prime example of why people prefer cauldron rather than bugfix. + + +><i> In any case, it seems to me that the bigger liability would be being out of sync with the 6-month +</I>><i> release cycle of kde, gnome, as well as many other distros. +</I> +s/many others distros/ubuntu and fedora/. + +Opensuse has a cycle of 8 months, Debian is not really time based ( and +is around 1 and 2 years ), Mandriva is gone on 1 year cycle, Arch, +Pclinuxos or others popular distributions from distrowatch do not seems +on a regular cycle. And as someone said, Mint is more released "when +ready after seeing fix on Ubuntu" than being a 6 months cycle ( even if +that's very similar ). + +-- +Michael Scherer + +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005844.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005864.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5847">[ date ]</a> + <a href="thread.html#5847">[ thread ]</a> + <a href="subject.html#5847">[ subject ]</a> + <a href="author.html#5847">[ 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> |