[Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

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