1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
|
<!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=%3C4DFDD21D.3010505%40laposte.net%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="005832.html">
<LINK REL="Next" HREF="005841.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=%3C4DFDD21D.3010505%40laposte.net%3E"
TITLE="[Mageia-dev] Release cycles proposals, and discussion">andr55 at laposte.net
</A><BR>
<I>Sun Jun 19 12:40:29 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="005832.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005841.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5840">[ date ]</a>
<a href="thread.html#5840">[ thread ]</a>
<a href="subject.html#5840">[ subject ]</a>
<a href="author.html#5840">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>andre999 a écrit :
><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> Proposal 1:
</I>>>>><i> 6 months release cycle -> 12 months life cycle
</I>>>>><i> ( Fedora, Ubuntu, Mandriva< 2010.1&& Mandriva != 2006.0 )
</I>>>>><i>
</I>>>>><i> Proposal 2:
</I>>>>><i> 9 months release cycle -> 18 months life cycle
</I>>>>><i> ( ~ opensuse and the one we used for Mageia 1 )
</I>>>>><i>
</I>>>>><i> Proposal 3:
</I>>>>><i> 12 months release cycle -> 24 months life cycle
</I>>>>><i> ( Mandriva> 2010.1 )
</I>>>><i>
</I>>>><i>
</I>>>><i> First, suggest an amended freeze process (idea from recent report of
</I>>>><i> another project)
</I>>><i>
</I>>><i> you can say the name of the project, even if I suspect it to be Fedora.
</I>><i>
</I>><i> I suspected that it might have been Fedora, if it wasn't a summary of
</I>><i> the new mozilla process, but I couldn't remember. Just the concept
</I>><i> intrigued me. Which I reflected on for a few weeks.
</I>><i>
</I>>>><i> Instead of a freeze on cauldron until everything is ready for the
</I>>>><i> release, we do
</I>>>><i> 1) short freeze on cauldron
</I>>>><i> 2) copy cauldron to pre-release branch, which remains frozen until
</I>>>><i> release
</I>>>><i> 3) immediately unfreeze cauldron.
</I>>>><i>
</I>>>><i> - we avoid blocking cauldron, while leaving pre-release frozen for
</I>>>><i> bug fixes.
</I>>>><i> - updates can continue on cauldron. Bugfixes can be applied to newer
</I>>>><i> versions, if present in
</I>>>><i> cauldron, at the same time as corresponding bugfixes in pre-release.
</I>>>><i> - activities like translation can continue in cauldron, meaning less
</I>>>><i> rush for such updates.
</I>>>><i> - because cauldron is open to changes (virtually) all the time, they
</I>>>><i> don't have to be put off and
</I>>>><i> perhaps forgotten.
</I>>>><i> - the cauldron cycle is extented by the time of the pre-release
</I>>>><i> freeze. e.g. In a release cycle of
</I>>>><i> 6 months and a pre-release freeze of 1 month, the cauldron cycle
</I>>>><i> would be 7 months.
</I>>>><i> This allows more time to iron out the pre-release bugs and more time
</I>>>><i> for cauldron.
</I>>>><i> - with the longer pre-release freeze, it may be appropriate to modify
</I>>>><i> somewhat the policy on what
</I>>>><i> is accepted during freeze. (Certain more recent packages or
</I>>>><i> translations, for example.)
</I>>>><i> - note that we would still have to monitor cauldron to avoid freezing
</I>>>><i> partially implemented complex
</I>>>><i> changes, such as a major update of kde or gnome or perl, etc. But we
</I>>>><i> have to do that now, anyway.
</I>>><i>
</I>>><i> So you suggest that in order to help packagers focusing on bug fixing,
</I>>><i> that we have them take care of cauldron and the bugfixes for the stable
</I>>><i> release ( ie, twice more the load ).
</I>><i>
</I>><i> I wouldn't quite put it that way ...
</I>><i>
</I>>>>><i> Proposal 1 :
</I>>>>><i> ---------------
</I>>>><i> My personal preference
</I>>>><i>
</I>>>>><i> Pros:
</I>>>>><i> - better hardware support
</I>>>>><i> - up to date versions / upstream projects (must have for developers)
</I>>>><i> - coincides with kde/gnome releases
</I>>>><i>
</I>>>><i> - amended freeze process (outlined above) would lengthen both
</I>>>><i> pre-release freeze time and cauldron
</I>>>><i> development time.
</I>>>><i> A 1-month pre-release freeze would add 1 month to cauldron
</I>>>><i> development time.
</I>>>><i> This would tend to alleviate the rush of the 6-month release cycle.
</I>>><i>
</I>>><i> Let's do some math, shall we ?
</I>><i>
</I>><i> great :)
</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 ? They
</I>><i> would just have a choice.
</I>><i> Now during the freeze, someone that wants to contribute to cauldron, but
</I>><i> can't or chooses not to contribute to pre-release bugfix, is not
</I>><i> contributing.
</I>><i> So in practice, we risk to have more time contributed during the freeze.
</I>><i>
</I>>><i> Let say :
</I>>><i> - the freeze period is Y weeks,
</I>>><i> - the time between 2 release is X weeks,
</I>>><i> - people divide their time evenly on both products.
</I>><i>
</I>><i> That wasn't assumed. Rather that as much time would be spent on bug
</I>><i> fixes, etc. in pre-release. But having a longer freeze period would
</I>><i> likely result in better quality, and certainly less rush.
</I>><i>
</I>>><i> That's a simplification, but I will come back on that later. Let's also
</I>>><i> count the time spent as the metrics for the work, even if man/month is a
</I>>><i> wrong unit in software development ( but that's a good enough
</I>>><i> approximation for our case, given the highly distributed and
</I>>><i> decentralized nature of the work of releasing a distribution ).
</I>>><i>
</I>>><i> So when there is the freeze ( at release(n) time - Y weeks ), we will
</I>>><i> have Y weeks of work done on both products ( next release, and cauldron
</I>>><i> ), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
</I>>><i> ( before the next freeze for release(n+1) ), and then again Y/2 weeks.
</I>>><i>
</I>>><i> So for the release (n+1), we spend :
</I>>><i> Y/2 + X - Y + Y/2
</I>>><i> = 2 * Y/2 - Y + X
</I>>><i> = Y - Y + X
</I>>><i> = X
</I>>><i>
</I>>><i> So that give X weeks of work. Fascinating, isn't it ?
</I>><i>
</I>><i> Not really. Being my basic assumption :)
</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> 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
</I>><i> give more time to focus on bug fixes.
</I>><i> Sure, there are updates and bug fixes in cauldron before the freeze, as
</I>><i> a normal part of any development process. (Even in the non-libre world.)
</I>><i>
</I>>><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
</I>><i> bug fixing during the longer freeze, but being less rushed, would tend
</I>><i> to produce better quality results. (And less aggravation for ennael)
</I>><i> (That is certainly how it works in the non-libre world.)
</I>><i>
</I>><i> I don't see how having the choice between contributing to pre-release or
</I>><i> cauldron during the freeze will lead to us loosing _any_ contributors.
</I>><i>
</I>><i> As well, since cauldron would be out of freeze virtually all the time,
</I>><i> there would be (virtually) no period where contributions to cauldron are
</I>><i> blocked.
</I>><i> Packager time is not an ubiquitous resource. Some packagers are perl
</I>><i> experts, other python, etc. Each packager is more familiar with some
</I>><i> packages than others. Some packagers are excellent developers; others
</I>><i> are challenged by basic scripts. There is a wide range of skills and
</I>><i> interests.
</I>><i>
</I>><i> If during freeze, a packager has a choice between attempting to help
</I>><i> with a bugfix in pre-release for a package with which s/he is not
</I>><i> familiar, or contributing to cauldron for something with which s/he is
</I>><i> familiar, it would be evidently more efficient to contribute to cauldron.
</I>><i>
</I>><i> Similarly, if a packager contributes a bug fix to pre-release, and a
</I>><i> newer package already exists in cauldron for which the same bug fix must
</I>><i> be applied, it is more efficient to apply the same patch right away,
</I>><i> than to wait until freeze is over. (Personnally I've encountered this
</I>><i> sort of situation with similar but different software many times. Any
</I>><i> experienced programmer should understand this point.)
</I>><i>
</I>><i> So there are a lot of (admittedly small) synergies which should lead to
</I>><i> packager time being more efficiently used.
</I>><i> Not counting the likelyhood that some packagers would contribute
</I>><i> somewhat more time, being able to contribute to cauldron during freeze.
</I>><i> The major benefit in my mind is the longer freeze period.
</I>><i>
</I>><i> How much this would help, I don't know. But I think it is worth a try.
</I>><i> (Even if we end up going for a 9-month release cycle, instead of my
</I>><i> preferred 6 months.)
</I>><i>
</I>
Another thought about the amended freeze process.
Have you noticed how packagers sometimes set off an exchange of 10 or more emails in attempts to
get a package into the release during the freeze ?
The packager wants to submit, but they can't because cauldron is frozen. Maybe if only pre-release
were frozen, but cauldron open, they would accept submitting to cauldron after only 1 or 2
exchanges. They would have the at least partial satisfaction of being able to submit their package
(instead of waiting, and doing something else, probably elsewhere), and others would have been
releaved of the hassle of dealing with their repeated requests.
I think that would be more motivating for the packager in question, as well as the others involved.
And packagers would avoid wasting both time and energy.
--
André
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="005832.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005841.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5840">[ date ]</a>
<a href="thread.html#5840">[ thread ]</a>
<a href="subject.html#5840">[ subject ]</a>
<a href="author.html#5840">[ 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>
|
