On Tuesday 11 Sep 2012 11:36:59 Stephan Kulow wrote:
* openSUSE 12.2 original schedule + 8 months = openSUSE 12.2 actual release + 4 months = Do a short cycle and release in March 2013, essentially 12.2 + bugfixes and updates
Aehm, March is 6 months away and that might be a short cycle for openSUSE, it's a business as usual for many other distributions. This would be my choice - especially as factory development already happened during 12.2 release. E.g. we integrated a new kernel, a new texlive, two new KDE versions, ... basically all before 12.2 was out.
My bad, it was a long night last night. 6 Month cycle.
* openSUSE 12.2 actual release + 8 months = May 2013, business as usual, using a fixed process to solve the problems that caused the 12.2 slip
And then? This is the biggest question in this concept - Release 13.1 in January 2014? No, thanks. - Release always in may afterwards with tumbleweed included in the process? Possible, but will need more drastic changes and I'm not sure we're there yet
* Extend the release cycle keeping same process and longer stabilization period (effective 12.2 release process; leads to shipping 'outdated' stuff)
12.2 has no outdated stuff, it has tested stuff. I beg to differ. But the stabilization period was not the problem with 12.2, the problem was that the time before that was for many "undirected hacking" and it was up to very few to get it together. A tendency that happens with long schedules I'm afraid.
Agreed, 'outdated' is just how your 'tested' gets perceived by the press and users.
* Change the process to plan more features in advance (as much as this is realistic given we mostly ship what our upstreams deliver) and work together to achieve these
As much as I like feature driven releases, they are just not relatistic to agree on in the project we're in. No matter what schedule we had in the past, there were always the voices to delay for X or Y.
I'll read that as "realistic" - although I would like to know what a relativistic release process would look like ;). Having some kind of feature planning is one area where I grudgingly envy Fedora (and to a lesser extent Ubuntu, although planning by diktat is easy). I don't want to break the discipline given by a time-based release, but I naively believe that the teams in the project can state what their upstreams will deliver, plus what they would like to engineer themselves, assign people to those and coordinate the impact with other teams, in a more structured way than mentioning something on -factory and then submitting an implementation to o:F at some later date. But I'm not arguing for some suffocating product design process either. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org