[Mageia-dev] Release cycles proposals, and discussion

Sun Jun 19 16:29:42 CEST 2011

Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+> >> Michael Scherer a écrit :
+
+> > If people work the same amount of time, with work divided on 2 products,
+> > they must share their time, and usually work less than if they focused
+> > only on one product, unless there is twice the ressources. But I doubt
+> > this will happen for us, so let's assume that ressources are fixed.
+> 
+> That was my assumption : resources fixed in terms of time spent.
+> And why would that divide a contributor's focus more than now ? 
+>  They would just have a choice.
+
+So before, the choice is between :
+- not doing anything
+- bugfixing
+
+After your proposal, there is :
+- not doing anything
+- bugfixing
+- uploading new stuff to cauldron 
+
+And you fail to see how it divert focus ?
+
+> Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to 
+> contribute to pre-release bugfix, is not contributing.
+> So in practice, we risk to have more time contributed during the freeze.
+
+My own experience tell the contrary, but maybe you should ask to Anne
+her opinion if you do not believe me, or to others people who did
+distribution releases ( and not software releases, which is slightly
+different, mainly because there is less  ).
+
+> > Now, of course, we can say "what if people do not divide their work in
+> > 2 ?"
+> >
+> > So let's call :
+> > - F the time spent on bugfix during the freeze
+> > - C the time spent on cauldron during the freeze
+> >
+> > We can assume that :
+> > C + F = Y
+> >
+> > So the equation become :
+> > C + ( X - Y ) + F
+> > = C + F - Y + X
+> > = X
+> >
+> > So no matter how you divide the time, you still have the same amount of
+> > time spent overall.
+> 
+> As I assumed :)
+
+No.
+"the cauldron cycle is extented by the time of the pre-release freeze.
+e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
+the cauldron cycle would be 7 months."
+
+The cauldron cycle would be 7 months just on the calendar, but 6 months
+worth of work, as demonstrated. 
+
+"A 1-month pre-release freeze would add 1 month to cauldron development
+time."
+
+That's the same, you do not add real months, just months on the
+calendar.
+
+> > Now, the real important question is "can we really exchange work done as
+> > part of C for work done as part of F".
+> >
+> > And so "if I do regular packages updates on cauldron at the begining of
+> > the cycle, does it count as bugfixing for the release in the end of the
+> > cycle" ?
+> >
+> > To me, the answer is clearly no. If it was somethig we could exchange,
+> > we would not have to make a freeze in the first place to make sure that
+> > only bugfixes are uploaded in cauldron.
+> >
+> > So the only way to maximize the time spent on bugfixes is to have F = Y,
+> > and so C = 0. Ie, do like we do now.
+> 
+> I really don't follow this line of reasoning.
+> The focus on bug fixes starts with the freeze.  So a longer freeze would give more time to focus on 
+> bug fixes.
+
+The focus on bugfixing start with version freeze, since what introduce
+problem is various changes, and new versions of softwares usually bring
+new changes. Then we block all uploads except bug fixes, and then all
+uploads unless very serious bug fixes ( ie, release blocker ). So the
+focus start much before the last freeze, and you are quite unclear.
+
+> > And unless you show that letting people work on cauldron will bring more
+> > ressources , and more than the one we will lose du to people who do not
+> > want to work on bugfixes and the release, I doubt this will change.
+> 
+> Ok.  Obviously I need to clarify my point of view.
+> Firstly, my assumption was that at least as much time would be spent on bug fixing during the 
+> longer freeze, but being less rushed, would tend to produce better quality results.  (And less 
+> aggravation for ennael)  (That is certainly how it works in the non-libre world.)
+
+You do not say much how you extend the freeze to be longer, nor even
+that the freeze appear sooner, reread your mail. Nor what kind of freeze
+would it be.
+
+The only mention of the duration of the freeze is :
+"A 1-month pre-release freeze would add 1 month to cauldron development
+time."
+
+The version freeze started on 20 april
+( https://mageia.org/pipermail/mageia-dev/20110419/004066.html ), which
+is more than 1 month. The release freeze was on 14 may, which is 2
+weeks. 
+
+Given that the version freeze is when we start to ask to people to focus
+on bugfixes and when we prevent packagers from uploading newer versions
+of packages, the proposed 1 month pre-release freeze is unclear and
+unexplained.
+
+
+> I don't see how having the choice between contributing to pre-release or cauldron during the freeze 
+> will lead to us loosing _any_ contributors.
+
+We do not lose contributors, we lose the work of people that prefer to
+work on cauldron by uploading new versions rather than bug fixing, and
+from people that will prefer to test and use cauldron rather than the
+future stable release, because that's easier, there is no deadline, nor
+any obligation, and there is newer stuff. 
+
+
+> If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release 
+> for a package with which s/he is not familiar, or contributing to cauldron for something with which 
+> s/he is familiar, it would be evidently more efficient to contribute to cauldron.
+
+You are placing a wrong dichotomy. The choice is not between "fixing
+something efficiently on cauldron vs fixing un-efficiently on
+pre-release", but between "fixing un-efficiently" vs "not fixing". 
+
+> Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists 
+> in cauldron for which the same bug fix must be applied, it is more efficient to apply the same 
+> patch right away, than to wait until freeze is over.  (Personnally I've encountered this sort of 
+> situation with similar but different software many times.  Any experienced programmer should 
+> understand this point.)
+
+With the current process, the fix is already applied for next cauldron
+cycle, since the package is the same, there is no branching.
+
+> So there are a lot of (admittedly small) synergies which should lead to packager time being more 
+> efficiently used.
+> Not counting the likelyhood that some packagers would contribute somewhat more time, being able to 
+> contribute to cauldron during freeze.
+> The major benefit in my mind is the longer freeze period.
+
+Which mean that we will have more outdated software if we freeze sooner.
+
+Assuming that the pre-release freeze you are speaking about is what the
+packagers know as "release freeze", this means the version freeze will
+be sooner too. Assuming that what you call "pre-release freeze" is the
+version freeze, then the freeze period would just be shorter.
+ 
+Also, your point seems to forget to take in account that people can
+focus on bugfixs without any freeze of the distribution, yet, they do
+not seems to do so. 
+
+People rushing packages in the last minute as it always happen is the
+prime example of why people prefer cauldron rather than bugfix.
+
+
+> In any case, it seems to me that the bigger liability would be being out of sync with the 6-month 
+> release cycle of kde, gnome, as well as many other distros.
+
+s/many others distros/ubuntu and fedora/.
+
+Opensuse has a cycle of 8 months, Debian is not really time based ( and
+is around 1 and 2 years ), Mandriva is gone on 1 year cycle, Arch,
+Pclinuxos or others popular distributions from distrowatch do not seems
+on a regular cycle. And as someone said, Mint is more released "when
+ready after seeing fix on Ubuntu" than being a 6 months cycle ( even if
+that's very similar ).
+
+-- 
+Michael Scherer
+
+