[Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 01:06 +0300, Sander Lepik a écrit :
> 12.06.2011 23:46, Michael Scherer kirjutas:
> > 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 )
>  From those options i would go with the second one. Third is way too much wanted from users 
> (and first has too short life cycle). They are always eager for new stuff and waiting one 
> year ain't option for them. We could also try to have some LTS versions. But in a bit 
> different manner than Ubuntu. Like if we notice that some release is good and stable we 
> could extend its support period (ie mdv2008.1 was really stabel and also mdv2010.1 was 
> pretty good - for me neither had too many problems and i would have keeped 2008.1 for longer 
> but its support ended).

The LTS discussion is for next week :)

> One more thing i didn't like with Mageia 1. Official launch date that you know is coming and 
> you see that not all things are ready for prime time but you go anyway as there is launch 
> date announced. Ubuntu has failed with that at least few times.
> Debian (Mozilla somewhat too) does better job here. They don't release if they see critical 
> problems and they don't announce release too far away.
> In that hurry we probably missed ATI graphics problem and could have solved it better.

Another solution is to  have a longer freeze period, so people focus
less on last minutes changes and packages upgrades, and more on bug
fixing.

And we also do not release if there is critical problem, the question is
more "what is critical". It must also be take in account that we didn't
finish the setup of infrastructure, so we will have likely more time and
less burden next time. 


> Maybe we should try to have 9 months but if it will be 10 with more stable release i would 
> go with 10 (or mabye final freeze in 8 months and then we'll see how fast we can make it 
> stable).
> 
> (And we have to keep up the good job with upgrading smoothness - in the future it must be 
> tested even more, that way users who want longer cycle will complain less if they can 
> upgrade their system w/o big problems.)

For that, I guess we could do automated upgrade testing, something
like : 
 - we setup a vm ( scriptable + tftp + pxe )
 - we install as much as possible ( auto installation )
 - we do a scripted upgrade ( auto installation + at / cron )
 - we check if it reboot fine ( a init script + a timeout somewhere ? )

this will not solve everything, but this would be a good start. The main
problem is to decide if the upgrade went well or not for all possible
case.

-- 
Michael Scherer