[Mageia-dev] Release cycles proposals, and discussion

[andre999]

Michael Scherer a écrit :

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


First, suggest an amended freeze process (idea from recent report of another project)
Instead of a freeze on cauldron until everything is ready for the release, we do
1) short freeze on cauldron
2) copy cauldron to pre-release branch, which remains frozen until release
3) immediately unfreeze cauldron.

- we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
- updates can continue on cauldron.  Bugfixes can be applied to newer versions, if present in 
cauldron, at the same time as corresponding bugfixes in pre-release.
- activities like translation can continue in cauldron, meaning less rush for such updates.
- because cauldron is open to changes (virtually) all the time, they don't have to be put off and 
perhaps forgotten.
- 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.
This allows more time to iron out the pre-release bugs and more time for cauldron.
- with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what 
is accepted during freeze.  (Certain more recent packages or translations, for example.)
- note that we would still have to monitor cauldron to avoid freezing partially implemented complex 
changes, such as a major update of kde or gnome or perl, etc.  But we have to do that now, anyway.


> Proposal 1 :
> ---------------
My personal preference

> Pros:
> - better hardware support
> - up to date versions / upstream projects (must have for developers)
- coincides with kde/gnome releases
- amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron 
development time.
A 1-month pre-release freeze would add 1 month to cauldron development time.
This would tend to alleviate the rush of the 6-month release cycle.

> - short life cycle
would be alleviated by having periodic long term support releases (lasting at least 2 years).


> Proposal 2
> ----------------
> Pros:
- amended freeze process outlined above would still be advantageous, to a lessor degree.

> Cons:
> - not synchronized with gnome or others that use a 6 month cycle
> - potentially release when there isn't much activity (like during Holidays)
- release would not be the same month every year
e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ...
so users won't know when to expect a release


> Proposal 3 :
> ------------
Would prefer to avoid this.

Additional cons :
- periodic long-term support releases with a shorter release cycle would be more advantageous, in 
terms of providing long-term stability for the few who would prefer it, while allowing a more 
up-to-date distro.
- requires more updates and backports, in order to keep up to date with upstream, which doesn't 
necessarily reduce workload over shorter release cycles.

my 2 cents :)

-- 
André