[Mageia-dev] Release cycles proposals, and discussion

Mon Jun 13 13:36:07 CEST 2011

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
+
+