[Mageia-dev] Release cycles proposals, and discussion

Mon Jun 13 15:08:51 CEST 2011

David Sjölin skrev 13.6.2011 16:00:
+> On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund<tmb at mageia.org>  wrote:
+>> Wolfgang Bornath skrev 13.6.2011 15:20:
+>>>
+>>> About the cycles:
+>>>
+>>> The 9-months seem to be a compromise - but I start to ask why we need
+>>> such a fixed statement (which it would be, once published). We need a
+>>> schedule for each cycle, that's true. Without a schedule we would
+>>> never finish anything. But how about taking 9 months only as a "nice
+>>> to meet" target, leaving us the option to set a roadmap after setting
+>>> the specs of the next release - we could then go for a 8 or 10 months
+>>> roadmap, depending on the specs.
+>>>
+>>
+>> This is somewhat like what I had in my mind to write too, but you beat me to
+>> it :)
+>>
+>> It could allow us to adapt a little for upstream releases.
+>> But should we then decide that the limit is +/- 1 month ?
+>>
+>> Obviously there will still be people complaining that "you waited 10
+>> months... if you had extended with ~2 more weeks... "this" or "that"
+>> package would have been available too... and so on....
+>>
+>>
+>> And something not to forget (this is more related to the specs):
+>>
+>> If an estimated upstream release of kde/gnome/... seem to fit our
+>> schedule it _must_ be in Cauldron before version freeze so we
+>> actually get some test/qa on it and not try to force it in by
+>> "hey it's released ~x days before final mageia release so it
+>>   must be added" attitude that tends to pop up at every freeze.
+>
+> This point and the one above ("if you had extended...") seems to be
+> arguments for a fixed time release cycle? With a fixed release cycle
+> no one would question why we didn't wait for the release of a new
+> gnome/kde/<any package which someone wants>, since waiting the extra
+> weeks would go against the release cycle. I'm not sure if that is
+> enough of an argument against having a looser release cycle but... But
+> then again, I can see the point of having the possibility to be a bit
+> flexible.
+
+Well, it was intended to point out the problem with the "flexible" 
+approach, and a possible "fix" by deciding some limits to the flexibility.
+
+--
+Thomas
+
+