David Sjölin skrev 13.6.2011 16:00:
On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund<[email protected]> 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
