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
|
<!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=%3C1308005449.24304.60.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="005500.html">
<LINK REL="Next" HREF="005663.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=%3C1308005449.24304.60.camel%40akroma.ephaone.org%3E"
TITLE="[Mageia-dev] Release cycles proposals, and discussion">misc at zarb.org
</A><BR>
<I>Tue Jun 14 00:50:48 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="005500.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005663.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5565">[ date ]</a>
<a href="thread.html#5565">[ thread ]</a>
<a href="subject.html#5565">[ subject ]</a>
<a href="author.html#5565">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le lundi 13 juin 2011 à 14:58 +0200, Samuel Verschelde a écrit :
><i> Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
</I>><i> > Hi,
</I>><i> >
</I>><i> > so , with a little bit delay due to various things ( like everybody
</I>><i> > asking stuff to us on irc on a hourly fashion ( people will I hope
</I>><i> > recognize themselves )), Anne and I have reviewed the various proposals
</I>><i> > made through years during the early period of the distribution, and
</I>><i> > before at Mandriva. We took in account the feedback of people on forum,
</I>><i> > on ml, nd those we have seen during events. We also discussed with
</I>><i> > others distributions developers we know from Opensuse, Fedora, Debian,
</I>><i> > Ubuntu about their release cycle, the choices they made and their
</I>><i> > reasons.
</I>><i>
</I>><i> A restitution to us of this overview of the other distros release cycles and
</I>><i> their choices, reasons, pros and cons would have been great, but I guess it
</I>><i> would have required much more time to write it.
</I>
Given that time is already lacking, yes.
But basically, Fedora use 6 months because they want to release often
( Features, First ), according to Mathieu Bridon. That's also why they
have a very agressive update policy ( which caused some issues like
xorg/nvidia breakage, firefox breakage, thunderbird problem ). They do
also have lots of upstream developers paid by RH, who prefer to have
this model to be able to have fast feedback on their software
( especially since almost no one run Rawhide, the equivalent of Cauldron
)
Discussing with Didier Roche, Ubuntu does this because they wanted to
release with gnome, every 6 months. There was discussion 1 year ago
about keeping a minimal distribution ( plateform model ) but it seems it
didn't happened yet. He also confirmed that the pace was quite intense,
letting them push lots of features they develop ( unity, etc ).
According to Vincent Untz, Opensuse moved from 6 months to 8 months
because they feel that 6 months was too much, too frequent. The only
problem is that 1 cycle about 3, they run older software ( like Gnome ),
but that's not a big problem.
I forgot the Debian stuff, but basically, their release model is a 3
tiered one ( testing, unstable, experimental ), with experimental is
were stuff that can break are uploaded, uploading almost everything,
unstable unstable
For obvious reason, everybody is happy of their choices :)
><i> It would have helped
</I>><i> understand why the final decision
</I>
If this as a final decision, I would not explain and ask to people their
opinion.
><i> you took was to keep the current model (not
</I>><i> counting the discussion about cycle duration and LTS). I'm not saying that I
</I>><i> want "rolling release", but beginning the discussion without saying much
</I>><i> concerning what has been a big discussion some months ago (and still is in the
</I>><i> forum) feels a bit weird to me. Especially when we kept telling people "wait,
</I>><i> we will have time to discuss it after Release 1".
</I>
Well, as I said, we didn't consider the "no release" option. After
looking the document you wrote
( <A HREF="http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle">http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle</A> ), the option
"no release" ( I ) was deemed as not realistic, and so was also our
opinion.
Now, we also took in account the summary and all others were a
combination of release policy, backports policy, and update policy.
Basically, on the release side, it was 1y or 6m, and we have seen that
everybody was only considering theses 2 propositions, hence the proposal
for 9 months ( partially inspired by the suse one ).
Something that was also apparent in your summary was the need to
backports lots of things on all proposals, the only difference being if
kernel/xorg would be backported or not depending on the release
frequency.
So after reading this, my conclusion on that was that the release model
would not change much on that part, since basically, either there is a
release often, or your proposal would be to backports lots of things. So
discussing release frequency only would be enough, since the other half
of the discussion is dependent on this one.
Or, as a mathematician would say :
backport_level(R) = stormi_constant / release_frequency(R)
( please not that you are now half as famous as Planck, Faraday and
Boltzmann since there is a constant named after you, the other half is
having a institute named after you )
><i> > To simplify the discussion, the proposals are all based on the fact that
</I>><i> > 2 or 3 releases could be supported at a time. We could have different
</I>><i> > schemes for that ( LTS every X release ( ubuntu ), different level of
</I>><i> > support ( mandriva )), but as this is a slightly different discussion,
</I>><i> > let's assume 2 supported releases for now, and let's discuss later for
</I>><i> > that ( ie next week, once this one is finished )
</I>><i>
</I>><i> I can understand the reason for separating the discussions (simplification),
</I>><i> but it's hard to give a final opinion concerning the release cycle without
</I>><i> knowing whether there will be a LTS or not, when you care about the life cycle
</I>><i> duration. The backports policy also has a great impact to the matter : if we
</I>><i> manage to make using newer versions of popular software easy without much risk
</I>><i> nor obligatory need to upgrade, extending the release cycle is easier (I could
</I>><i> go with 12 months provided we find a way to improve hardware support as part of
</I>><i> the maintenance).
</I>
As I said, having read your proposals, the only difference was backport
or not, and the previous discussion about release showed that changing
several parameter at the same time would lead to a complexity
explosion :
- with or without lts,
-> for lts, how long, and how often
that's already likely 5 propositions per itself
- 6, 9, 12, or 8, 10 months, or variable ( like 6 one time, 12 another
time ). We can surely have 7 propositions for that ( taking the "no
release option" ).
Updates policy could be :
- 1 release, 2 release, 3 releases, 4 releases
- full, not full ( ie like Mandriva ), different for LTS
Let's assume 8 different variations.
So, in total, discussing everything at the same time, this would be :
8 * 5 * 7 = 280 combinations.
Now, let's add a backport policy. We can have backport lots of thing,
backport nothing, backport some stuff, and I think we can safely speak
of 4 or 5 different policies.
So that's between 1280 and 1400 possibilities.
If we assume that 90% of the propositions are bogus ( which is far from
the reality, that's IMHO quite the contrary ), that's still 100
possibility to discuss, and even with a so extreme and dictatorial
removal, that's not manageable.
So no, after doing the math, discussing everything at once is not
doable.
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="005500.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005663.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5565">[ date ]</a>
<a href="thread.html#5565">[ thread ]</a>
<a href="subject.html#5565">[ subject ]</a>
<a href="author.html#5565">[ 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>
|
