diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005442.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005442.html | 318 |
1 files changed, 318 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005442.html b/zarb-ml/mageia-dev/2011-June/005442.html new file mode 100644 index 000000000..af6022170 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005442.html @@ -0,0 +1,318 @@ +<!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=%3C1307911593.29591.56.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="005528.html"> + <LINK REL="Next" HREF="005443.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=%3C1307911593.29591.56.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">misc at zarb.org + </A><BR> + <I>Sun Jun 12 22:46:33 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005528.html">[Mageia-dev] update of compiz +</A></li> + <LI>Next message: <A HREF="005443.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5442">[ date ]</a> + <a href="thread.html#5442">[ thread ]</a> + <a href="subject.html#5442">[ subject ]</a> + <a href="author.html#5442">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Hi, + +so , with a little bit delay due to various things ( like everybody +asking stuff to us on irc on a hourly fashion ( people will I hope +recognize themselves )), Anne and I have reviewed the various proposals +made through years during the early period of the distribution, and +before at Mandriva. We took in account the feedback of people on forum, +on ml, nd those we have seen during events. We also discussed with +others distributions developers we know from Opensuse, Fedora, Debian, +Ubuntu about their release cycle, the choices they made and their +reasons. + +Before going to the proposal, a few point of vocabulary : + +Release cycle mean the time between 2 releases. + +Life cycle means the time where we offer the distribution on most +mirrors, and plan to offer infra for that ( backports, security update +), and accept/correct bugs. IE, "support" on the distribution level. + + +To simplify the discussion, the proposals are all based on the fact that +2 or 3 releases could be supported at a time. We could have different +schemes for that ( LTS every X release ( ubuntu ), different level of +support ( mandriva )), but as this is a slightly different discussion, +let's assume 2 supported releases for now, and let's discuss later for +that ( ie next week, once this one is finished ) + +And roughly, to start the discussion, we have 3 potential releases +cycles, based on all inputs we had : + +Proposal 1: +6 months release cycle -> 12 months life cycle +( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 ) + +Proposal 2: +9 months release cycle -> 18 months life cycle +( ~ opensuse and the one we used for Mageia 1 ) + +Proposal 3: +12 months release cycle -> 24 months life cycle +( Mandriva > 2010.1 ) + + + +Proposal 1 : +--------------- +Pros: +- better hardware support +- up to date versions / upstream projects (must have for developers) + + +Cons: +- very tight schedule: must include brainstorm, specifications, +developments, development releases +- feeling to be releasing all the time +- short lifecycle ( nothing long term ) + + +Proposal 2 +---------------- +Pros: +- compromise between proposal 1 and proposal 3 +- development release more manageable to include all steps +- allow to release when no others distributions , so we can be sure to +have enough communication + + +Cons: +- not synchronized with gnome or others that use a 6 month cycle +- potentially release when there isn't much activity ( like during +Holidays ) + + +Proposal 3 : +------------ + +Pros: +- users do upgrade less often, as this is often seen as tedious. +- asked by some professionnal users + + +Cons: +- less visibility, because there is less communication +- coders and packagers feel some urge to push last minute feature to not +wait one year, adding difficulty to manage the planning on 1 year +without intermediary release +- hardware support potentially lagging behind + + + +Astute readers will see that the 3 proposals are all time based and the +2 alternatives type of release would be : +- no release +- features based. + +We didn't develop any proposal on them. +The no-release model is not really a release cycle per definition ( if +the release planning is to do nothing, that's not a planning ). + +The feature based model ( aka "release when it is ready" ), while being +tempting, is a dangerous path, since too many project are late due to +lack of formal planning. Being based on features add more complexity on +something like a distribution given the wide scale of change to +implement, and the high number of interaction. So it was not taken in +account for that. + + +Out of theses 3 propositions, Anne was in favor of the version 2 ( 9 +months ), based on her experience with 1 ( Mandriva ) and 3 ( Mandriva +2006.0 ). + +I was personally pleased with 1 and 3 as a user, mainly because I am +perfectly able to take care of any issue, so I am not really in a +position to give a preference. ( I use desktop and server, even if the +dichotomy is rather "stuff that I want to upgrade often" ( personal +workstation, home server ) and "stuff that I prefer to not upgrade +often" ( parents workstation, some external server ). + + +Now, remember the rules. + +- all proposals must be justified ( and why they are better than the +current ones ). + +- the discussion will finished the 22 June. After that, it is too late +until we rediscuss again ( like a few years if everything changed ). + +- if no clear consensus emerge, we will have to decide using another +way. It will likely make some people sad if their favorite option is not +the one used, but such is life. + +- if the discussion become unmanageable, remember the pictures in topic +of the irc channel of sysadmins. + + +Now, if someone could point others teams to this discussion, this would +be helpful. Anne promised me to send a note to english forums about +that. + +But do not forward the mail, ask to people to speak on -dev rather than +discuss on $others_comm_channel ( like irc, forum, others mls ). People +not posting on -dev will lose their right to complain they were not +listened. If someone is volunteer to gather feedback for their own +group, it will be fine. + + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005528.html">[Mageia-dev] update of compiz +</A></li> + <LI>Next message: <A HREF="005443.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5442">[ date ]</a> + <a href="thread.html#5442">[ thread ]</a> + <a href="subject.html#5442">[ subject ]</a> + <a href="author.html#5442">[ 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> |