diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005565.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005565.html | 286 |
1 files changed, 286 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005565.html b/zarb-ml/mageia-dev/2011-June/005565.html new file mode 100644 index 000000000..8fb0d49a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005565.html @@ -0,0 +1,286 @@ +<!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=%3C1308005449.24304.60.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="005500.html"> + <LINK REL="Next" HREF="005663.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=%3C1308005449.24304.60.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">misc at zarb.org + </A><BR> + <I>Tue Jun 14 00:50:48 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005500.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005663.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5565">[ date ]</a> + <a href="thread.html#5565">[ thread ]</a> + <a href="subject.html#5565">[ subject ]</a> + <a href="author.html#5565">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 13 juin 2011 à 14:58 +0200, Samuel Verschelde a écrit : +><i> Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit : +</I>><i> > Hi, +</I>><i> > +</I>><i> > so , with a little bit delay due to various things ( like everybody +</I>><i> > asking stuff to us on irc on a hourly fashion ( people will I hope +</I>><i> > recognize themselves )), Anne and I have reviewed the various proposals +</I>><i> > made through years during the early period of the distribution, and +</I>><i> > before at Mandriva. We took in account the feedback of people on forum, +</I>><i> > on ml, nd those we have seen during events. We also discussed with +</I>><i> > others distributions developers we know from Opensuse, Fedora, Debian, +</I>><i> > Ubuntu about their release cycle, the choices they made and their +</I>><i> > reasons. +</I>><i> +</I>><i> A restitution to us of this overview of the other distros release cycles and +</I>><i> their choices, reasons, pros and cons would have been great, but I guess it +</I>><i> would have required much more time to write it. +</I> +Given that time is already lacking, yes. + +But basically, Fedora use 6 months because they want to release often +( Features, First ), according to Mathieu Bridon. That's also why they +have a very agressive update policy ( which caused some issues like +xorg/nvidia breakage, firefox breakage, thunderbird problem ). They do +also have lots of upstream developers paid by RH, who prefer to have +this model to be able to have fast feedback on their software +( especially since almost no one run Rawhide, the equivalent of Cauldron +) + +Discussing with Didier Roche, Ubuntu does this because they wanted to +release with gnome, every 6 months. There was discussion 1 year ago +about keeping a minimal distribution ( plateform model ) but it seems it +didn't happened yet. He also confirmed that the pace was quite intense, +letting them push lots of features they develop ( unity, etc ). + +According to Vincent Untz, Opensuse moved from 6 months to 8 months +because they feel that 6 months was too much, too frequent. The only +problem is that 1 cycle about 3, they run older software ( like Gnome ), +but that's not a big problem. + +I forgot the Debian stuff, but basically, their release model is a 3 +tiered one ( testing, unstable, experimental ), with experimental is +were stuff that can break are uploaded, uploading almost everything, +unstable unstable + +For obvious reason, everybody is happy of their choices :) + +><i> It would have helped +</I>><i> understand why the final decision +</I> +If this as a final decision, I would not explain and ask to people their +opinion. + +><i> you took was to keep the current model (not +</I>><i> counting the discussion about cycle duration and LTS). I'm not saying that I +</I>><i> want "rolling release", but beginning the discussion without saying much +</I>><i> concerning what has been a big discussion some months ago (and still is in the +</I>><i> forum) feels a bit weird to me. Especially when we kept telling people "wait, +</I>><i> we will have time to discuss it after Release 1". +</I> +Well, as I said, we didn't consider the "no release" option. After +looking the document you wrote +( <A HREF="http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle">http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle</A> ), the option +"no release" ( I ) was deemed as not realistic, and so was also our +opinion. + +Now, we also took in account the summary and all others were a +combination of release policy, backports policy, and update policy. +Basically, on the release side, it was 1y or 6m, and we have seen that +everybody was only considering theses 2 propositions, hence the proposal +for 9 months ( partially inspired by the suse one ). + +Something that was also apparent in your summary was the need to +backports lots of things on all proposals, the only difference being if +kernel/xorg would be backported or not depending on the release +frequency. + +So after reading this, my conclusion on that was that the release model +would not change much on that part, since basically, either there is a +release often, or your proposal would be to backports lots of things. So +discussing release frequency only would be enough, since the other half +of the discussion is dependent on this one. + +Or, as a mathematician would say : +backport_level(R) = stormi_constant / release_frequency(R) + +( please not that you are now half as famous as Planck, Faraday and +Boltzmann since there is a constant named after you, the other half is +having a institute named after you ) + +><i> > To simplify the discussion, the proposals are all based on the fact that +</I>><i> > 2 or 3 releases could be supported at a time. We could have different +</I>><i> > schemes for that ( LTS every X release ( ubuntu ), different level of +</I>><i> > support ( mandriva )), but as this is a slightly different discussion, +</I>><i> > let's assume 2 supported releases for now, and let's discuss later for +</I>><i> > that ( ie next week, once this one is finished ) +</I>><i> +</I>><i> I can understand the reason for separating the discussions (simplification), +</I>><i> but it's hard to give a final opinion concerning the release cycle without +</I>><i> knowing whether there will be a LTS or not, when you care about the life cycle +</I>><i> duration. The backports policy also has a great impact to the matter : if we +</I>><i> manage to make using newer versions of popular software easy without much risk +</I>><i> nor obligatory need to upgrade, extending the release cycle is easier (I could +</I>><i> go with 12 months provided we find a way to improve hardware support as part of +</I>><i> the maintenance). +</I> +As I said, having read your proposals, the only difference was backport +or not, and the previous discussion about release showed that changing +several parameter at the same time would lead to a complexity +explosion : +- with or without lts, + -> for lts, how long, and how often +that's already likely 5 propositions per itself + +- 6, 9, 12, or 8, 10 months, or variable ( like 6 one time, 12 another +time ). We can surely have 7 propositions for that ( taking the "no +release option" ). + +Updates policy could be : +- 1 release, 2 release, 3 releases, 4 releases +- full, not full ( ie like Mandriva ), different for LTS + +Let's assume 8 different variations. + +So, in total, discussing everything at the same time, this would be : +8 * 5 * 7 = 280 combinations. + +Now, let's add a backport policy. We can have backport lots of thing, +backport nothing, backport some stuff, and I think we can safely speak +of 4 or 5 different policies. + +So that's between 1280 and 1400 possibilities. + +If we assume that 90% of the propositions are bogus ( which is far from +the reality, that's IMHO quite the contrary ), that's still 100 +possibility to discuss, and even with a so extreme and dictatorial +removal, that's not manageable. + +So no, after doing the math, discussing everything at once is not +doable. + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005500.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005663.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5565">[ date ]</a> + <a href="thread.html#5565">[ thread ]</a> + <a href="subject.html#5565">[ subject ]</a> + <a href="author.html#5565">[ 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> |