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/005453.html | 237 +++++++++++++++++++++++++++++++ 1 file changed, 237 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005453.html (limited to 'zarb-ml/mageia-dev/2011-June/005453.html') diff --git a/zarb-ml/mageia-dev/2011-June/005453.html b/zarb-ml/mageia-dev/2011-June/005453.html new file mode 100644 index 000000000..beab704fd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005453.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 13 00:48:17 CEST 2011 +

+
+ +
Op zondag 12 juni 2011 23:38:48 schreef Angelo Naselli:
+> In data domenica 12 giugno 2011 22:46:33, Michael Scherer ha scritto:
+> > 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 )
+> 
+> Well imo extending too much release cycle means also to
+> have a lot of backports and patches for fixings.
+> 
+> So 1 or 2 are better, more upstream packages than fixings.
+> 
+> If we cannot afford 6 mo release cycle because we're all volunteers for
+> instance, 9 mo one is the right compromise, i believe.
+> 
+> Cheers,
+
++1
+
+allthough, _perhaps_ there is another option: (i didn't think about the effect 
+this would have on life cycles):
+
+i was thinking, that maybe we want 9months now, because of big changes coming, 
+but maybe in the future we would do less big changes for instance.
+
+Proposal 4:
+JIT-fixed months release cycle -> ? months life cycle
+
+explanation:
+the idea is to have the following things happen after release:
+1. postmortem
+2. discussion of features
+3. decision of features
+4. making planning and deciding time based on the featurelist and an educated 
+guess on time required to implement and bugfix. (generally between 6 and 12 
+months)
+....
+
+pro:
+ - allows to plan release taking into account everything:
+    - list of features to be done (and amount of packagers)
+    - holidays
+    - releases of other distros
+    - stuff i hadn't thought of
+
+con:
+ - there could be a pitfall that we ALWAYS don't fulfill the planning
+ - unknown months life cycle
+
+
+in general, it would mean, what we do right now, there's a separate decision 
+every time.
+
+thinking specifically on this time:
+ - 8months: 1st febr, bad idea: because of christmas holidays there will 
+likely be no good testing.
+ - 9months is 1st march? (sounds like a busy time for other distros)
+ - 10months:  1st april (april fools joke? not good)
+
+I'm thinking 10,5 months for this one: April 15th. perhaps next time most big 
+changes will be done, and we could go for a short 6 or 7month release if we 
+have more resources at that time.
+
+just my personal opinion,
+
+Maarten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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