[Mageia-dev] Release cycles proposals, and discussion

Thu Jun 23 05:04:30 CEST 2011

andre999 a écrit :
+> Michael Scherer a écrit :
+>>
+>> 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
+> - or doing something elsewhere.
+>>
+>> After your proposal, there is :
+>> - not doing anything
+>> - bugfixing
+>> - uploading new stuff to cauldron
+>>
+>> And you fail to see how it divert focus ?
+>
+> We have to remember that packager time is not an ubiquitous resource. If
+> a packager cannot use their time efficiently during freeze, they have
+> incentive to contribute their time elsewhere. It is just human nature.
+> Admittedly this is more likely to affect packagers with less broad-based
+> skills, but such packagers do not make insignificant contributions.
+> As far as diverting focus, does the existance of many distros, providing
+> much more choice, divert focus ? Likely to some extent, but not many
+> packagers contribute to 4 to 6 distros and support in the order of 1000
+> packages. That's more the exception, for packagers with exceptional skills.
+>
+>>> 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 ).
+>
+> Until we try it, we don't know how much effect it will have. To the best
+> of my knowledge Mandrake/Mandriva and certainly Mageia has not tried
+> this approach. We are both working on conjectures, and we can't know
+> until we (or some other distro with similar resources) tries it.
+> I find it difficult to believe that it will have a negative effect. And
+> I think it would be useful to try it early in the development of Mageia.
+> Even experienced programmers, who have to support different versions of
+> the same software, run into cases where it is very convient -- and more
+> efficient -- to do parallel updates for example. I run into that often
+> enough myself.
+>
+>>>> 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."
+>
+> Agreed. I've already said that.
+>
+>> 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.
+>
+> As I said, my basic assumption that the same number of packager hours
+> are contributed. Certain factors suggest that one could expect somewhat
+> more time contributed, and a number of others that the time would be
+> used more efficiently. Nothing suggests that less time would be available.
+>
+>>>> 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.
+>
+> It terms of freeze, I'm referring to the first freeze for the release.
+> The different stages will happen (more or less) as they do now.
+>
+>>>> 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.
+>
+> If this scheme were adopted, such details would probably be best decided
+> by those most experienced with the process, above all ennael, and
+> packagers such as yourself. Offhand, maybe 2 weeks longer would be
+> adequate, to give less rush and compensate for contributions to
+> non-freeze cauldron.
+> (See also above.)
+>
+>> 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.
+>
+> One month was an arbitrary figure, just to demonstrate the principle.
+> Obviously from what you say, it would be longer. (It did seem much much
+> longer.)
+> My idea was to have a somewhat (but not excessively) longer freeze period.
+>
+>>> 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.
+>
+> So you fear a lack of commitment by packagers. That is a different
+> question.
+> I think that packagers can be motivated to help. But maybe those
+> demotivated by their inability to contribute efficiently to pre-release
+> will contribute to cauldron during the freeze ? That's not a loss.
+>
+>>> 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".
+>
+> In my world, those unable to contribute efficiently are much less
+> motivated to contribute. So this change could have the effect to more
+> motivate less experienced packagers. Which could be a big plus in the
+> longer term.
+> So although your dichotomy would apply to many packagers, particularly
+> those more skilled, definitely not all.
+>
+>>> 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.
+>
+> Suppose that during freeze a packager discovers an important bug fix
+> patch along with a newer version. The patch must be applied to both the
+> current and newer version, the latter being blocked from going into the
+> freeze. So the fix must be applied to both. So why can't the packager
+> put the newer version into cauldron and apply the patch, if they have
+> time ? It would be a more efficient use of time.
+>
+>>> 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.
+>
+> But not as outdated (on average during the cycle) as it would be if we
+> go from a 6-month to 9-month release cycle. I'm suggesting a difference
+> probably in the order of weeks.
+>
+>> 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.
+>
+> I was thinking of the first freeze, when there starts to be a lot of
+> focus on bug fixes. This would allow immediate unfreeze of cauldron. But
+> maybe it would be better for the second stage. A lot of packages (if not
+> most) will have a different version for the subsequent release, so bug
+> fixes -- even if the same patch -- would have to be applied separately
+> for the subsequent release, anyway.
+> Any packages patched for pre-release could be simply copied back to
+> cauldron, as well. The process could be even automated.
+>
+>> 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.
+>
+> Basically I assumed that.
+>
+>> People rushing packages in the last minute as it always happen is the
+>> prime example of why people prefer cauldron rather than bugfix.
+>
+> But doesn't blocking cauldron during freeze reinforce this behavior ?
+>
+>>> 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/.
+>
+> OK. Mostly just the 2 biggest distros.
+>
+>> 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 ).
+>
+> I still see short_cauldron_freeze + copy_to_pre-release +
+> unfreeze_cauldron as a better approach.
+> Even if we do go for a 9-month release cycle.
+>
+> It is not as though we would be adopting the parallel development scheme
+> of Mozilla, having a number of parallel branches in development at the
+> same time. That would require much more work.
+> It would only be for the freeze period.
+>
+> Having cauldron blocked for 6 weeks seems excessive. Many packagers are
+> left with little to contribute. And in certain cases, even those focused
+> and efficient on bug fixes, will find it advantageous to be able to make
+> updates to cauldron which are currently blocked.
+>
+> another 2 cents :)
+>
+
+I'd like to consolidate and clarify my ideas regarding an amended freeze process, taking into 
+account the critiques.
+That is, that for the freeze which leads to the release, that we
+1) freeze cauldron
+2) copy caudron to a pre-release branch, which remains frozen, and will become the release
+3) then unfreeze cauldron.
+
+- this would be the first freeze, when the big focus starts on bug fixes.  The sequence of freeze 
+types would not (necessarily) change.
+- although cauldron would be unfrozen, the idea is to allow small contributions, such as new 
+packages, new versions not accepted into pre-release, etc.
+But not to have major changes which could break cauldron, as the main contributors will be focused, 
+as now, on pre-release, and major breaks in cauldron should be quickly fixed.
+So that cauldron would not be not totally blocked to all non-release contributions during the 
+freeze period (which was about 6 weeks for mga1).
+- It would probably be very useful to have an explicit policy limiting the nature of contributions 
+to cauldron during the pre-release period.  We could even encourage the importing of new packages 
+during this period.
+- Caudron unfrozen would also allow less experienced packagers to contribute to cauldron at times 
+when they are unable to usefully contribute to pre-release.  For instance, such packagers could 
+depend heavily on the advice of others for bug fixes, but could be advanced enough to import new 
+packages or new versions to cauldron on their own.  (idea from comment on mageia1_postmortum wiki 
+page.)
+- This process assumes that the freeze period would be extended (by maybe 2 weeks) to give more 
+time to fix bugs, relieving some of the pressure.  Those less able to efficiently contribute to 
+pre-release could contribute to cauldron, so the extra time would be needed.
+- If this amended process allows us to more easily make the release, and thus keep the release 
+cycle of 6 months, we would have the advantage of keeping in sync with upstream for major projects 
+such as kde and gnome.  But if not enough for keeping the 6-month release cycle, if it helps, let's 
+use it if we go with a longer cycle.
+- In no way is the idea to produce parallel development streams as is now done by mozilla for firefox.
+
+Hopefully this summary helps.
+(BTW, it is still Wednesday in my time zone.)
+On the road to mga2 ... :)
+-- 
+André
+