[Mageia-dev] Release cycles proposals, and discussion

[andre999]

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é