[Mageia-dev] Release cycles proposals, and discussion

Tue Jun 14 22:21:31 CEST 2011

Op dinsdag 14 juni 2011 04:08:34 schreef Michael Scherer:
+> Le mardi 14 juin 2011 à 03:30 +0200, Maarten Vanraes a écrit :
+> > 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:
+> > > > 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.
+> 
+> See my answer to wobo.
+
+i did read that, that's partly a reason why i'm saying this. I think with the 
+proper whips things get in order, as we did, and i'm sure that no matter what 
+the eventual planning will be (in no matter what project), whippings will 
+always be needed, or the said project will never finish at all...
+
+so imho an 8month planning could be possible, or a 7.5month planning. it's 
+just that whatever the planning, we should follow it. (pending 
+release_critical of course)
+
+> > We proved that we can take a planning and follow it through, even the
+> > last release_critical one was solved _just_in_time_...
+> 
+> I still think the codecs stuff should not have been release_critical, as
+> we could do the update later.
+
+that is true, but i still think that would be bad, as:
+A) there is still no update afaik (and there have been reviews)
+B) even when updates is there, to properly solve it, it also still need some 
+work
+
+and eventually, those tainted stuff would likely take 3months or more.
+
+i'm pretty sure some people who review will likely play mp3s...
+
+but ok, that's passed now (but we still need to solve it the right way, let's 
+not forget this).
+
+> > 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.
+> 
+> Great, so can you start by telling how long it will take for the feature
+> you plan to work on ?
+
+tbh, in my dayjob, that's often required of me to make an estimation. and if 
+we ARE going down that route, then of course i will do it. if you can't even 
+try an estimation for the things that you want to do, will you even start 
+doing them...
+
+fwiw, i think that 1month before freeze time, it's really clear which features 
+will get there in time and which won't.
+
+as an example; i knew right of the bat, that the maintainer db would not be 
+ready, and iinm i did warn about that. ok, it's not critical, but it would 
+still be very usefull.
+
+if we have a proper version control environment, it should be easy to drop 
+feature that aren't going to be in time, and are postponed for next release...
+
+in any case, let us know at the end if an estimation is required, and i'll 
+gladly do that
+