On Mon, 13 Jun 2011, Wolfgang Bornath wrote:
About the cycles:
The problems with 6-months have been pointed out - my main concern
would be the lack of manpower and the continuous state of
"pre-release", no real room to sit back and contemplate hwat is and
what could be and all the rest. IMHO such a "contemplating" time is
necessary to keep the whole picture in focus.
The problems with 12-months have also been pointed out and I agree
with them (too long out of public focus, too long for the main
userland applications, etc.).
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 being said, I am a friend of a rolling release like ArchLinux,
but I fear that our main target group is not up to this. Despite of
having to "burn yet another DVD" as somebody pointed out, the majority
seems to see this as normal and a good way. Of course I may be totally
wrong with this assessment!
+1
The consensus so far seems to be:
6 months is too short
12 months is too long
9 months is juuuuust about right
and that applies not only to developers having a chance to catch their breath
between versions, but
users too. A 6-month turnaround feels like I'm constantly updating, but a
12-month wait between
versions is like forever. And as wobo suggests, 9 months need be only an
average, with a target date
for the next release, taking into account upstream developments, decided on
after each one. Also,
the target date should be approximate at first and firmed up only as we get
closer to release.
spock
