[Mageia-dev] Release cycles proposals, and discussion

Tue Jun 14 00:50:48 CEST 2011

Le lundi 13 juin 2011 à 14:58 +0200, Samuel Verschelde a écrit :
+> Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
+> > Hi,
+> > 
+> > so , with a little bit delay due to various things ( like everybody
+> > asking stuff to us on irc on a hourly fashion ( people will I hope
+> > recognize themselves )), Anne and I have reviewed the various proposals
+> > made through years during the early period of the distribution, and
+> > before at Mandriva. We took in account the feedback of people on forum,
+> > on ml, nd those we have seen during events. We also discussed with
+> > others distributions developers we know from Opensuse, Fedora, Debian,
+> > Ubuntu about their release cycle, the choices they made and their
+> > reasons.
+> 
+> A restitution to us of this overview of the other distros release cycles and 
+> their choices, reasons, pros and cons would have been great, but I guess it 
+> would have required much more time to write it.
+
+Given that time is already lacking, yes.
+
+But basically, Fedora use 6 months because they want to release often
+( Features, First ), according to Mathieu Bridon. That's also why they
+have a very agressive update policy ( which caused some issues like
+xorg/nvidia breakage, firefox breakage, thunderbird problem ). They do
+also have lots of upstream developers paid by RH, who prefer to have
+this model to be able to have fast feedback on their software
+( especially since almost no one run Rawhide, the equivalent of Cauldron
+)
+
+Discussing with Didier Roche, Ubuntu does this because they wanted to
+release with gnome, every 6 months. There was discussion 1 year ago
+about keeping a minimal distribution ( plateform model ) but it seems it
+didn't happened yet. He also confirmed that the pace was quite intense,
+letting them push lots of features they develop ( unity, etc ).
+
+According to Vincent Untz, Opensuse moved from 6 months to 8 months
+because they feel that 6 months was too much, too frequent. The only
+problem is that 1 cycle about 3, they run older software ( like Gnome ),
+but that's not a big problem. 
+
+I forgot the Debian stuff, but basically, their release model is a 3
+tiered one ( testing, unstable, experimental ), with experimental is
+were stuff that can break are uploaded, uploading almost everything,
+unstable unstable
+
+For obvious reason, everybody is happy of their choices :)
+
+>  It would have helped 
+> understand why the final decision
+
+If this as a final decision, I would not explain and ask to people their
+opinion. 
+
+>  you took was to keep the current model (not 
+> counting the discussion about cycle duration and LTS). I'm not saying that I 
+> want "rolling release", but beginning the discussion without saying much 
+> concerning what has been a big discussion some months ago (and still is in the 
+> forum) feels a bit weird to me. Especially when we kept telling people "wait, 
+> we will have time to discuss it after Release 1".
+
+Well, as I said, we didn't consider the "no release" option. After
+looking the document you wrote
+( http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle ), the option
+"no release" ( I ) was deemed as not realistic, and so was also our
+opinion. 
+
+Now, we also took in account the summary and all others were a
+combination of release policy, backports policy, and update policy.
+Basically, on the release side, it was 1y or 6m, and we have seen that
+everybody was only considering theses 2 propositions, hence the proposal
+for 9 months ( partially inspired by the suse one ). 
+
+Something that was also apparent in your summary was the need to
+backports lots of things on all proposals, the only difference being if
+kernel/xorg would be backported or not depending on the release
+frequency. 
+
+So after reading this, my conclusion on that was that the release model
+would not change much on that part, since basically, either there is a
+release often, or your proposal would be to backports lots of things. So
+discussing release frequency only would be enough, since the other half
+of the discussion is dependent on this one.
+
+Or, as a mathematician would say : 
+backport_level(R) = stormi_constant / release_frequency(R) 
+
+( please not that you are now half as famous as Planck, Faraday and
+Boltzmann since there is a constant named after you, the other half is
+having a institute named after you )
+
+> > To simplify the discussion, the proposals are all based on the fact that
+> > 2 or 3 releases could be supported at a time. We could have different
+> > schemes for that ( LTS every X release ( ubuntu ), different level of
+> > support ( mandriva )), but as this is a slightly different discussion,
+> > let's assume 2 supported releases for now, and let's discuss later for
+> > that ( ie next week, once this one is finished )
+> 
+> I can understand the reason for separating the discussions (simplification), 
+> but it's hard to give a final opinion concerning the release cycle without 
+> knowing whether there will be a LTS or not, when you care about the life cycle 
+> duration. The backports policy also has a great impact to the matter : if we 
+> manage to make using newer versions of popular software easy without much risk 
+> nor obligatory need to upgrade, extending the release cycle is easier (I could 
+> go with 12 months provided we find a way to improve hardware support as part of 
+> the maintenance).
+
+As I said, having read your proposals, the only difference was backport
+or not, and the previous discussion about release showed that changing
+several parameter at the same time would lead to a complexity
+explosion :
+- with or without lts,
+  -> for lts, how long, and how often 
+that's already likely 5 propositions per itself
+
+- 6, 9, 12, or 8, 10 months, or variable ( like 6 one time, 12 another
+time ). We can surely have 7 propositions for that ( taking the "no
+release option" ).
+
+Updates policy could be : 
+- 1 release, 2 release, 3 releases, 4 releases
+- full, not full ( ie like Mandriva ), different for LTS 
+
+Let's assume 8 different variations.
+
+So, in total, discussing everything at the same time, this would be :
+8 * 5 * 7 = 280 combinations.
+
+Now, let's add a backport policy. We can have backport lots of thing,
+backport nothing, backport some stuff, and I think we can safely speak
+of 4 or 5 different policies.
+
+So that's between 1280 and 1400 possibilities. 
+
+If we assume that 90% of the propositions are bogus ( which is far from
+the reality, that's IMHO quite the contrary ), that's still 100
+possibility to discuss, and even with a so extreme and dictatorial
+removal, that's not manageable.
+
+So no, after doing the math, discussing everything at once is not
+doable. 
+
+-- 
+Michael Scherer
+
+