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

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 03:30:56 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
+> Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
+> > Wolfgang Bornath skrev 13.6.2011 15:20:
+> > > About the cycles:
+> > > 
+> > > The 9-months seem to be a compromise - but I start to ask why we need
+> > > such a fixed statement (which it would be, once published). We need a
+> > > schedule for each cycle, that's true. Without a schedule we would
+> > > never finish anything. But how about taking 9 months only as a "nice
+> > > to meet" target, leaving us the option to set a roadmap after setting
+> > > the specs of the next release - we could then go for a 8 or 10 months
+> > > roadmap, depending on the specs.
+> > 
+> > This is somewhat like what I had in my mind to write too, but you beat
+> > me to it :)
+> > 
+> > It could allow us to adapt a little for upstream releases.
+> > But should we then decide that the limit is +/- 1 month ?
+> 
+> There is 2 problem :
+> - for release of what software ?
+> - what if the upstream planning is wrong, and their releases is late
+> ( as it happened when I was a trainee in Mandrakesoft, with xfree being
+> 3 months late and the distribution still shipping a broken pre release )
+> 
+> > Obviously there will still be people complaining that "you waited 10
+> > months... if you had extended with ~2 more weeks... "this" or "that"
+> > package would have been available too... and so on....
+> 
+> Yes, there will be.
+> So let's be realist, 9 months with +/- 1 month is just 10 months +
+> people complaining to have 10,5 months.
+> 
+> We will never use the -1 month, because there will always be something
+> worth waiting.
+
+actually, the real reason would be more to plan for whatever features you're 
+going to implement and the time it takes to do them. if that's 8 months, it's 
+8 months, if that's 9 or 10months, that's what it is.
+
+We proved that we can take a planning and follow it through, even the last 
+release_critical one was solved _just_in_time_...
+
+imho, we need to decide now on a sort of 9month period, look at what we're 
+going to do, then estimating how long it takes (with enough lenience), then 
+make a real planning for that, and stick to it, if features are not ready, 
+drop those features for next release, and make sure to fix all the 
+release_criticals.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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