[Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

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