[Mageia-dev] Release cycles proposals, and discussion

[Thomas Backlund]

David Sjölin skrev 13.6.2011 16:00:
> On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund<tmb at mageia.org>  wrote:
>> 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 ?
>>
>> 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....
>>
>>
>> And something not to forget (this is more related to the specs):
>>
>> If an estimated upstream release of kde/gnome/... seem to fit our
>> schedule it _must_ be in Cauldron before version freeze so we
>> actually get some test/qa on it and not try to force it in by
>> "hey it's released ~x days before final mageia release so it
>>   must be added" attitude that tends to pop up at every freeze.
>
> This point and the one above ("if you had extended...") seems to be
> arguments for a fixed time release cycle? With a fixed release cycle
> no one would question why we didn't wait for the release of a new
> gnome/kde/<any package which someone wants>, since waiting the extra
> weeks would go against the release cycle. I'm not sure if that is
> enough of an argument against having a looser release cycle but... But
> then again, I can see the point of having the possibility to be a bit
> flexible.

Well, it was intended to point out the problem with the "flexible" 
approach, and a possible "fix" by deciding some limits to the flexibility.

--
Thomas