diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20110613/30ac67d2/attachment-0001.html')
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20110613/30ac67d2/attachment-0001.html | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20110613/30ac67d2/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20110613/30ac67d2/attachment-0001.html new file mode 100644 index 000000000..1ba6b26a0 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20110613/30ac67d2/attachment-0001.html @@ -0,0 +1,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> |