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
|
<!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=%3C1308493783.11316.269.camel%40akroma.ephaone.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="005844.html">
<LINK REL="Next" HREF="005864.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Release cycles proposals, and discussion</H1>
<B>Michael Scherer</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Release%20cycles%20proposals%2C%20and%20discussion&In-Reply-To=%3C1308493783.11316.269.camel%40akroma.ephaone.org%3E"
TITLE="[Mageia-dev] Release cycles proposals, and discussion">misc at zarb.org
</A><BR>
<I>Sun Jun 19 16:29:42 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="005844.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005864.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5847">[ date ]</a>
<a href="thread.html#5847">[ thread ]</a>
<a href="subject.html#5847">[ subject ]</a>
<a href="author.html#5847">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le samedi 18 juin 2011 à 23:49 -0400, 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> > 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>
So before, the choice is between :
- not doing anything
- bugfixing
After your proposal, there is :
- not doing anything
- bugfixing
- uploading new stuff to cauldron
And you fail to see how it divert focus ?
><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>
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 ).
><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>
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."
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.
><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>
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.
><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>
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.
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
( <A HREF="https://mageia.org/pipermail/mageia-dev/20110419/004066.html">https://mageia.org/pipermail/mageia-dev/20110419/004066.html</A> ), 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.
><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>
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.
><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>
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".
><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>
With the current process, the fix is already applied for next cauldron
cycle, since the package is the same, there is no branching.
><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>
Which mean that we will have more outdated software if we freeze sooner.
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.
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.
People rushing packages in the last minute as it always happen is the
prime example of why people prefer cauldron rather than bugfix.
><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>
s/many others distros/ubuntu and fedora/.
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 ).
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="005844.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005864.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5847">[ date ]</a>
<a href="thread.html#5847">[ thread ]</a>
<a href="subject.html#5847">[ subject ]</a>
<a href="author.html#5847">[ 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>
|
