From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-June/005809.html | 159 +++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005809.html (limited to 'zarb-ml/mageia-dev/2011-June/005809.html') diff --git a/zarb-ml/mageia-dev/2011-June/005809.html b/zarb-ml/mageia-dev/2011-June/005809.html new file mode 100644 index 000000000..4ad493c63 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005809.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Sat Jun 18 09:38:49 CEST 2011 +

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

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1