diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005950.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005950.html | 393 |
1 files changed, 393 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005950.html b/zarb-ml/mageia-dev/2011-June/005950.html new file mode 100644 index 000000000..c4c700053 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005950.html @@ -0,0 +1,393 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Release cycles proposals, and discussion + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Release%20cycles%20proposals%2C%20and%20discussion&In-Reply-To=%3C4E02AD3E.7060402%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005864.html"> + <LINK REL="Next" HREF="005951.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Release cycles proposals, and discussion</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Release%20cycles%20proposals%2C%20and%20discussion&In-Reply-To=%3C4E02AD3E.7060402%40laposte.net%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">andr55 at laposte.net + </A><BR> + <I>Thu Jun 23 05:04:30 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005864.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005951.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5950">[ date ]</a> + <a href="thread.html#5950">[ thread ]</a> + <a href="subject.html#5950">[ subject ]</a> + <a href="author.html#5950">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>andre999 a écrit : +><i> Michael Scherer a écrit : +</I>>><i> +</I>>><i> Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit : +</I>>>><i> Michael Scherer a écrit : +</I>>>>><i> +</I>>>>><i> Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : +</I>>>>>><i> Michael Scherer a écrit : +</I>>><i> +</I>>>>><i> If people work the same amount of time, with work divided on 2 +</I>>>>><i> products, +</I>>>>><i> they must share their time, and usually work less than if they focused +</I>>>>><i> only on one product, unless there is twice the ressources. But I doubt +</I>>>>><i> this will happen for us, so let's assume that ressources are fixed. +</I>>>><i> +</I>>>><i> That was my assumption : resources fixed in terms of time spent. +</I>>>><i> And why would that divide a contributor's focus more than now ? +</I>>>><i> They would just have a choice. +</I>>><i> +</I>>><i> So before, the choice is between : +</I>>><i> - not doing anything +</I>>><i> - bugfixing +</I>><i> - or doing something elsewhere. +</I>>><i> +</I>>><i> After your proposal, there is : +</I>>><i> - not doing anything +</I>>><i> - bugfixing +</I>>><i> - uploading new stuff to cauldron +</I>>><i> +</I>>><i> And you fail to see how it divert focus ? +</I>><i> +</I>><i> We have to remember that packager time is not an ubiquitous resource. If +</I>><i> a packager cannot use their time efficiently during freeze, they have +</I>><i> incentive to contribute their time elsewhere. It is just human nature. +</I>><i> Admittedly this is more likely to affect packagers with less broad-based +</I>><i> skills, but such packagers do not make insignificant contributions. +</I>><i> As far as diverting focus, does the existance of many distros, providing +</I>><i> much more choice, divert focus ? Likely to some extent, but not many +</I>><i> packagers contribute to 4 to 6 distros and support in the order of 1000 +</I>><i> packages. That's more the exception, for packagers with exceptional skills. +</I>><i> +</I>>>><i> Now during the freeze, someone that wants to contribute to cauldron, +</I>>>><i> but can't or chooses not to +</I>>>><i> contribute to pre-release bugfix, is not contributing. +</I>>>><i> So in practice, we risk to have more time contributed during the freeze. +</I>>><i> +</I>>><i> My own experience tell the contrary, but maybe you should ask to Anne +</I>>><i> her opinion if you do not believe me, or to others people who did +</I>>><i> distribution releases ( and not software releases, which is slightly +</I>>><i> different, mainly because there is less ). +</I>><i> +</I>><i> Until we try it, we don't know how much effect it will have. To the best +</I>><i> of my knowledge Mandrake/Mandriva and certainly Mageia has not tried +</I>><i> this approach. We are both working on conjectures, and we can't know +</I>><i> until we (or some other distro with similar resources) tries it. +</I>><i> I find it difficult to believe that it will have a negative effect. And +</I>><i> I think it would be useful to try it early in the development of Mageia. +</I>><i> Even experienced programmers, who have to support different versions of +</I>><i> the same software, run into cases where it is very convient -- and more +</I>><i> efficient -- to do parallel updates for example. I run into that often +</I>><i> enough myself. +</I>><i> +</I>>>>><i> Now, of course, we can say "what if people do not divide their work in +</I>>>>><i> 2 ?" +</I>>>>><i> +</I>>>>><i> So let's call : +</I>>>>><i> - F the time spent on bugfix during the freeze +</I>>>>><i> - C the time spent on cauldron during the freeze +</I>>>>><i> +</I>>>>><i> We can assume that : +</I>>>>><i> C + F = Y +</I>>>>><i> +</I>>>>><i> So the equation become : +</I>>>>><i> C + ( X - Y ) + F +</I>>>>><i> = C + F - Y + X +</I>>>>><i> = X +</I>>>>><i> +</I>>>>><i> So no matter how you divide the time, you still have the same amount of +</I>>>>><i> time spent overall. +</I>>>><i> +</I>>>><i> As I assumed :) +</I>>><i> +</I>>><i> No. +</I>>><i> "the cauldron cycle is extented by the time of the pre-release freeze. +</I>>><i> e.g. In a release cycle of 6 months and a pre-release freeze of 1 month, +</I>>><i> the cauldron cycle would be 7 months." +</I>><i> +</I>><i> Agreed. I've already said that. +</I>><i> +</I>>><i> The cauldron cycle would be 7 months just on the calendar, but 6 months +</I>>><i> worth of work, as demonstrated. +</I>>><i> +</I>>><i> "A 1-month pre-release freeze would add 1 month to cauldron +</I>>><i> development time." +</I>>><i> +</I>>><i> That's the same, you do not add real months, just months on the calendar. +</I>><i> +</I>><i> As I said, my basic assumption that the same number of packager hours +</I>><i> are contributed. Certain factors suggest that one could expect somewhat +</I>><i> more time contributed, and a number of others that the time would be +</I>><i> used more efficiently. Nothing suggests that less time would be available. +</I>><i> +</I>>>>><i> Now, the real important question is "can we really exchange work +</I>>>>><i> done as +</I>>>>><i> part of C for work done as part of F". +</I>>>>><i> +</I>>>>><i> And so "if I do regular packages updates on cauldron at the begining of +</I>>>>><i> the cycle, does it count as bugfixing for the release in the end of the +</I>>>>><i> cycle" ? +</I>>>>><i> +</I>>>>><i> To me, the answer is clearly no. If it was somethig we could exchange, +</I>>>>><i> we would not have to make a freeze in the first place to make sure that +</I>>>>><i> only bugfixes are uploaded in cauldron. +</I>>>>><i> +</I>>>>><i> So the only way to maximize the time spent on bugfixes is to have F +</I>>>>><i> = Y, +</I>>>>><i> and so C = 0. Ie, do like we do now. +</I>>>><i> +</I>>>><i> I really don't follow this line of reasoning. +</I>>>><i> The focus on bug fixes starts with the freeze. So a longer freeze +</I>>>><i> would give more time to focus on +</I>>>><i> bug fixes. +</I>>><i> +</I>>><i> The focus on bugfixing start with version freeze, since what introduce +</I>>><i> problem is various changes, and new versions of softwares usually bring +</I>>><i> new changes. Then we block all uploads except bug fixes, and then all +</I>>><i> uploads unless very serious bug fixes ( ie, release blocker ). So the +</I>>><i> focus start much before the last freeze, and you are quite unclear. +</I>><i> +</I>><i> It terms of freeze, I'm referring to the first freeze for the release. +</I>><i> The different stages will happen (more or less) as they do now. +</I>><i> +</I>>>>><i> And unless you show that letting people work on cauldron will bring +</I>>>>><i> more +</I>>>>><i> ressources , and more than the one we will lose du to people who do not +</I>>>>><i> want to work on bugfixes and the release, I doubt this will change. +</I>>>><i> +</I>>>><i> Ok. Obviously I need to clarify my point of view. +</I>>>><i> Firstly, my assumption was that at least as much time would be spent +</I>>>><i> on bug fixing during the +</I>>>><i> longer freeze, but being less rushed, would tend to produce better +</I>>>><i> quality results. (And less +</I>>>><i> aggravation for ennael) (That is certainly how it works in the +</I>>>><i> non-libre world.) +</I>>><i> +</I>>><i> You do not say much how you extend the freeze to be longer, nor even +</I>>><i> that the freeze appear sooner, reread your mail. Nor what kind of freeze +</I>>><i> would it be. +</I>><i> +</I>><i> If this scheme were adopted, such details would probably be best decided +</I>><i> by those most experienced with the process, above all ennael, and +</I>><i> packagers such as yourself. Offhand, maybe 2 weeks longer would be +</I>><i> adequate, to give less rush and compensate for contributions to +</I>><i> non-freeze cauldron. +</I>><i> (See also above.) +</I>><i> +</I>>><i> The only mention of the duration of the freeze is : +</I>>><i> "A 1-month pre-release freeze would add 1 month to cauldron development +</I>>><i> time." +</I>>><i> +</I>>><i> The version freeze started on 20 april +</I>>><i> ( <A HREF="https://mageia.org/pipermail/mageia-dev/20110419/004066.html">https://mageia.org/pipermail/mageia-dev/20110419/004066.html</A> ), which +</I>>><i> is more than 1 month. The release freeze was on 14 may, which is 2 +</I>>><i> weeks. +</I>>><i> +</I>>><i> Given that the version freeze is when we start to ask to people to focus +</I>>><i> on bugfixes and when we prevent packagers from uploading newer versions +</I>>><i> of packages, the proposed 1 month pre-release freeze is unclear and +</I>>><i> unexplained. +</I>><i> +</I>><i> One month was an arbitrary figure, just to demonstrate the principle. +</I>><i> Obviously from what you say, it would be longer. (It did seem much much +</I>><i> longer.) +</I>><i> My idea was to have a somewhat (but not excessively) longer freeze period. +</I>><i> +</I>>>><i> I don't see how having the choice between contributing to pre-release +</I>>>><i> or cauldron during the freeze +</I>>>><i> will lead to us loosing _any_ contributors. +</I>>><i> +</I>>><i> We do not lose contributors, we lose the work of people that prefer to +</I>>><i> work on cauldron by uploading new versions rather than bug fixing, and +</I>>><i> from people that will prefer to test and use cauldron rather than the +</I>>><i> future stable release, because that's easier, there is no deadline, nor +</I>>><i> any obligation, and there is newer stuff. +</I>><i> +</I>><i> So you fear a lack of commitment by packagers. That is a different +</I>><i> question. +</I>><i> I think that packagers can be motivated to help. But maybe those +</I>><i> demotivated by their inability to contribute efficiently to pre-release +</I>><i> will contribute to cauldron during the freeze ? That's not a loss. +</I>><i> +</I>>>><i> If during freeze, a packager has a choice between attempting to help +</I>>>><i> with a bugfix in pre-release +</I>>>><i> for a package with which s/he is not familiar, or contributing to +</I>>>><i> cauldron for something with which +</I>>>><i> s/he is familiar, it would be evidently more efficient to contribute +</I>>>><i> to cauldron. +</I>>><i> +</I>>><i> You are placing a wrong dichotomy. The choice is not between "fixing +</I>>><i> something efficiently on cauldron vs fixing un-efficiently on +</I>>><i> pre-release", but between "fixing un-efficiently" vs "not fixing". +</I>><i> +</I>><i> In my world, those unable to contribute efficiently are much less +</I>><i> motivated to contribute. So this change could have the effect to more +</I>><i> motivate less experienced packagers. Which could be a big plus in the +</I>><i> longer term. +</I>><i> So although your dichotomy would apply to many packagers, particularly +</I>><i> those more skilled, definitely not all. +</I>><i> +</I>>>><i> Similarly, if a packager contributes a bug fix to pre-release, and a +</I>>>><i> newer package already exists +</I>>>><i> in cauldron for which the same bug fix must be applied, it is more +</I>>>><i> efficient to apply the same +</I>>>><i> patch right away, than to wait until freeze is over. (Personnally +</I>>>><i> I've encountered this sort of +</I>>>><i> situation with similar but different software many times. Any +</I>>>><i> experienced programmer should +</I>>>><i> understand this point.) +</I>>><i> +</I>>><i> With the current process, the fix is already applied for next cauldron +</I>>><i> cycle, since the package is the same, there is no branching. +</I>><i> +</I>><i> Suppose that during freeze a packager discovers an important bug fix +</I>><i> patch along with a newer version. The patch must be applied to both the +</I>><i> current and newer version, the latter being blocked from going into the +</I>><i> freeze. So the fix must be applied to both. So why can't the packager +</I>><i> put the newer version into cauldron and apply the patch, if they have +</I>><i> time ? It would be a more efficient use of time. +</I>><i> +</I>>>><i> So there are a lot of (admittedly small) synergies which should lead +</I>>>><i> to packager time being more +</I>>>><i> efficiently used. +</I>>>><i> Not counting the likelyhood that some packagers would contribute +</I>>>><i> somewhat more time, being able to +</I>>>><i> contribute to cauldron during freeze. +</I>>>><i> The major benefit in my mind is the longer freeze period. +</I>>><i> +</I>>><i> Which mean that we will have more outdated software if we freeze sooner. +</I>><i> +</I>><i> But not as outdated (on average during the cycle) as it would be if we +</I>><i> go from a 6-month to 9-month release cycle. I'm suggesting a difference +</I>><i> probably in the order of weeks. +</I>><i> +</I>>><i> Assuming that the pre-release freeze you are speaking about is what the +</I>>><i> packagers know as "release freeze", this means the version freeze will +</I>>><i> be sooner too. Assuming that what you call "pre-release freeze" is the +</I>>><i> version freeze, then the freeze period would just be shorter. +</I>><i> +</I>><i> I was thinking of the first freeze, when there starts to be a lot of +</I>><i> focus on bug fixes. This would allow immediate unfreeze of cauldron. But +</I>><i> maybe it would be better for the second stage. A lot of packages (if not +</I>><i> most) will have a different version for the subsequent release, so bug +</I>><i> fixes -- even if the same patch -- would have to be applied separately +</I>><i> for the subsequent release, anyway. +</I>><i> Any packages patched for pre-release could be simply copied back to +</I>><i> cauldron, as well. The process could be even automated. +</I>><i> +</I>>><i> Also, your point seems to forget to take in account that people can +</I>>><i> focus on bugfixs without any freeze of the distribution, yet, they do +</I>>><i> not seems to do so. +</I>><i> +</I>><i> Basically I assumed that. +</I>><i> +</I>>><i> People rushing packages in the last minute as it always happen is the +</I>>><i> prime example of why people prefer cauldron rather than bugfix. +</I>><i> +</I>><i> But doesn't blocking cauldron during freeze reinforce this behavior ? +</I>><i> +</I>>>><i> In any case, it seems to me that the bigger liability would be being +</I>>>><i> out of sync with the 6-month +</I>>>><i> release cycle of kde, gnome, as well as many other distros. +</I>>><i> +</I>>><i> s/many others distros/ubuntu and fedora/. +</I>><i> +</I>><i> OK. Mostly just the 2 biggest distros. +</I>><i> +</I>>><i> Opensuse has a cycle of 8 months, Debian is not really time based ( and +</I>>><i> is around 1 and 2 years ), Mandriva is gone on 1 year cycle, Arch, +</I>>><i> Pclinuxos or others popular distributions from distrowatch do not seems +</I>>><i> on a regular cycle. And as someone said, Mint is more released "when +</I>>><i> ready after seeing fix on Ubuntu" than being a 6 months cycle ( even if +</I>>><i> that's very similar ). +</I>><i> +</I>><i> I still see short_cauldron_freeze + copy_to_pre-release + +</I>><i> unfreeze_cauldron as a better approach. +</I>><i> Even if we do go for a 9-month release cycle. +</I>><i> +</I>><i> It is not as though we would be adopting the parallel development scheme +</I>><i> of Mozilla, having a number of parallel branches in development at the +</I>><i> same time. That would require much more work. +</I>><i> It would only be for the freeze period. +</I>><i> +</I>><i> Having cauldron blocked for 6 weeks seems excessive. Many packagers are +</I>><i> left with little to contribute. And in certain cases, even those focused +</I>><i> and efficient on bug fixes, will find it advantageous to be able to make +</I>><i> updates to cauldron which are currently blocked. +</I>><i> +</I>><i> another 2 cents :) +</I>><i> +</I> +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é +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005864.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005951.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5950">[ date ]</a> + <a href="thread.html#5950">[ thread ]</a> + <a href="subject.html#5950">[ subject ]</a> + <a href="author.html#5950">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |