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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] about release cycle
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20about%20release%20cycle&In-Reply-To=%3C726644.65720.qm%40web161318.mail.bf1.yahoo.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="005951.html">
<LINK REL="Next" HREF="005452.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] about release cycle</H1>
<B>Ron</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20about%20release%20cycle&In-Reply-To=%3C726644.65720.qm%40web161318.mail.bf1.yahoo.com%3E"
TITLE="[Mageia-dev] about release cycle">corbintechboy at yahoo.com
</A><BR>
<I>Mon Jun 13 00:25:43 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="005951.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005452.html">[Mageia-dev] autologin + consolekit
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5451">[ date ]</a>
<a href="thread.html#5451">[ thread ]</a>
<a href="subject.html#5451">[ subject ]</a>
<a href="author.html#5451">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Hello,
I hope I am doing this right as I have never used this type of thing before, I will apologize before hand if not.
I wrote a proposal on the forums and I think it is very good and I would like it at the very least just heard and seen if it might work in the ideals of the project. I joined this list to get this out here. I am going to do copy/paste from my original post(s) to get this here.. Post 1:
Here is what I propose:
Unstable- This is the place where it all starts! Packages come from upstream end up here and move forward if no show stopper bugs are found
Rolling Unstable- Packages that leave Unstable come here to be tested for stability and made stable... Bleeding edge rolling (Debian Unstable)
Rolling Stable- Packages that are stable in Rolling Unstable for X amount of time come here.... Stable rolling (Arch)
Point releases- These releases are taken from the stable rolling release and supported for X amount of time... Security updates only 
LTS release- These are rock solid stable (Debian stable) and snap shots from point release on whole number
So we would have unstable (easy to understand), unstable rolling for those who want cutting edge software, stable rolling for those who want to roll stable, point releases for those who like to install every now and then and LTS which after the way down the line should be VERY stable!
Further info:
1 developer releases 1 package. Package maintainer pulls package into unstable (developers don't make a habit of making crappy packages, stability is judged by the whole system running in harmony). Maintainers job is to make sure it works before it leaves unstable. When the package gains stability in unstable (basically you are able to install the package and have a usable system) the package moves to the next stage, rolling unstable. Rolling unstable is a test bed of bleeding edge software from the package maintainer for a X amount of time (we are still on this one package). Now, the next time this package moves it is from a scheduled pull, so this package after X amount of time now gets "pulled" into the next phase (rolling stable (as long as there are no show stopper bugs)). From here on out the "team" responsible pulls in packages from up stream (rolling unstable) and the package maintainer just repeats this process in working at the top of the
ladder. Security updates and bug fixes can be "pushed" down by the maintainer.
Where is this hard? Sounds like any other distribution to me... Debian maybe?
Anyway...
2.0 will become an LTS. Not a packaging nightmare at all... A snapshot of rolling stable from a point in time that matures with bug fixes and security updates. Kernel only updates within kernel branch (2.6.30-XX).
2.1 is a point release... Snapshot of rolling unstable (again easy on package maintainer). Supported for X amount of time. Becomes slightly mature as bug fixes and core updates make it so (from stuff already coming down from up stream).
So we have 1 package maintainer working packages that are pushed into rolling unstable (think testing) and trickle on down the line with help from the community team of "distribution" maintainers.
One rolling set of packages ever changing like a fine oiled machine. The logic just sounds right to me and very efficient I think...
EDIT: If you wanted to "shorten" the amount of "projects (I guess)" you could omit anything below rolling unstable.
Rolling unstable for instance could roll into a full fledged release (Not a good idea IMHO)
Rolling stable we could do without and we would be Debian all over (maybe more bleeding edge on the release)
LTS does not have to be... But LTS would be a very good way to get us used on servers...
Point releases are for those who don't like the rolling model... This is a "showcase" release to show everyone what we are without having to roll 
Up to anyone really but this model is so versatile it really don't matter. You could omit about any point below the maintainer and have working mechanics.________________________________________________________________________Last post was in response to a disagreement with someone else. To help make my idea more fitting I was suggesting ways within my idea where things can change. Was under the impression the other part thought the idea would be hard on the package maintainer, I didn't and still don't see this problem. With everything being snapshots of the rolling model, maintaining should be very easy.
We could become fully rolling with this model, rolling and stable (debian but with newer packages), rolling unstable with LTS releases, rolling with general releases... Really there are a lot of possibilities based on this model. 
I like it...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/mageia-dev/attachments/20110612/1fc5ea8a/attachment.html>
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="005951.html">[Mageia-dev] Release cycles proposals, and discussion
</A></li>
<LI>Next message: <A HREF="005452.html">[Mageia-dev] autologin + consolekit
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5451">[ date ]</a>
<a href="thread.html#5451">[ thread ]</a>
<a href="subject.html#5451">[ subject ]</a>
<a href="author.html#5451">[ 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>
|
