[Mageia-dev] Release cycles proposals, and discussion

Sun Jun 12 22:46:33 CEST 2011

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
+
+