blob: 1ba6b26a0331a9777002ddff280bd9ec6d44ce89 (
plain)
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
|
<br><br><div class="gmail_quote">2011/6/13 Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org">tmb@mageia.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Wolfgang Bornath skrev 13.6.2011 15:20:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
About the cycles:<div class="im"><br>
<br>
The 9-months seem to be a compromise - but I start to ask why we need<br>
such a fixed statement (which it would be, once published). We need a<br>
schedule for each cycle, that's true. Without a schedule we would<br>
never finish anything. But how about taking 9 months only as a "nice<br>
to meet" target, leaving us the option to set a roadmap after setting<br>
the specs of the next release - we could then go for a 8 or 10 months<br>
roadmap, depending on the specs.<br>
<br>
</div></blockquote>
<br>
This is somewhat like what I had in my mind to write too, but you beat me to it :)<br>
<br>
It could allow us to adapt a little for upstream releases.<br>
But should we then decide that the limit is +/- 1 month ?<br>
<br>
Obviously there will still be people complaining that "you waited 10 months... if you had extended with ~2 more weeks... "this" or "that"<br>
package would have been available too... and so on....<br>
<br>
<br>
And something not to forget (this is more related to the specs):<br>
<br>
If an estimated upstream release of kde/gnome/... seem to fit our<br>
schedule it _must_ be in Cauldron before version freeze so we<br>
actually get some test/qa on it and not try to force it in by<br>
"hey it's released ~x days before final mageia release so it<br>
must be added" attitude that tends to pop up at every freeze.<br>
<br>
--<br><font color="#888888">
Thomas<br>
<br>
<br>
<br>
</font></blockquote></div>Let the 9 months as maximum, as a general target.<div><br></div><div>Make the specs and then the roadmap with a fixed release date and a fixed enough time for freeze and testing.</div><div><br></div>
<div>If an upstream release brings conflits, that's live.</div><div>Main focus should be a stable release for simple users not a pot of the latest apps</div><div><br></div><div>Magnus</div><div><br></div>
|
