diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2011-June/005864.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-1be510f9529cb082f802408b472a77d074b394c0.tar archives-1be510f9529cb082f802408b472a77d074b394c0.tar.gz archives-1be510f9529cb082f802408b472a77d074b394c0.tar.bz2 archives-1be510f9529cb082f802408b472a77d074b394c0.tar.xz archives-1be510f9529cb082f802408b472a77d074b394c0.zip | |
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005864.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005864.html | 323 |
1 files changed, 323 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005864.html b/zarb-ml/mageia-dev/2011-June/005864.html new file mode 100644 index 000000000..e4f5396b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005864.html @@ -0,0 +1,323 @@ +<!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=%3C4DFE9AA4.5050104%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005847.html"> + <LINK REL="Next" HREF="005950.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=%3C4DFE9AA4.5050104%40laposte.net%3E" + TITLE="[Mageia-dev] Release cycles proposals, and discussion">andr55 at laposte.net + </A><BR> + <I>Mon Jun 20 02:56:04 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005847.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005950.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5864">[ date ]</a> + <a href="thread.html#5864">[ thread ]</a> + <a href="subject.html#5864">[ subject ]</a> + <a href="author.html#5864">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael Scherer a écrit : +><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 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>- or doing something elsewhere. +><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> +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. + +>><i> Now during the freeze, someone that wants to contribute to cauldron, 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> +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. + +>>><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> +Agreed. I've already said that. + +><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 development time." +</I>><i> +</I>><i> That's the same, you do not add real months, just months on the calendar. +</I> +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. + +>>><i> Now, the real important question is "can we really exchange work 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 = 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 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> +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. + +>>><i> And unless you show that letting people work on cauldron will bring 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 on bug fixing during the +</I>>><i> longer freeze, but being less rushed, would tend to produce better quality results. (And less +</I>>><i> aggravation for ennael) (That is certainly how it works in the 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> +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.) + +><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> +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> I don't see how having the choice between contributing to pre-release 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> +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. + +>><i> If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release +</I>>><i> for a package with which s/he is not familiar, or contributing to cauldron for something with which +</I>>><i> s/he is familiar, it would be evidently more efficient to contribute 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> +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. + +>><i> Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists +</I>>><i> in cauldron for which the same bug fix must be applied, it is more efficient to apply the same +</I>>><i> patch right away, than to wait until freeze is over. (Personnally I've encountered this sort of +</I>>><i> situation with similar but different software many times. Any 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> +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. + +>><i> So there are a lot of (admittedly small) synergies which should lead to packager time being more +</I>>><i> efficiently used. +</I>>><i> Not counting the likelyhood that some packagers would contribute 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> +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. + +><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 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. + +><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> +Basically I assumed that. + +><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> +But doesn't blocking cauldron during freeze reinforce this behavior ? + +>><i> In any case, it seems to me that the bigger liability would be being 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> +OK. Mostly just the 2 biggest distros. + +><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 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 :) + +-- +André +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005847.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI>Next message: <A HREF="005950.html">[Mageia-dev] Release cycles proposals, and discussion +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5864">[ date ]</a> + <a href="thread.html#5864">[ thread ]</a> + <a href="subject.html#5864">[ subject ]</a> + <a href="author.html#5864">[ 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> |