On Mar 5, 2009, at 5:00 AM, Stephan Kulow <coolo@novell.com> wrote:
Hi,
As you may have noticed, we have yet to publish a roadmap for 11.2. The reason is simple: There are a lot of moving pieces at the moment, and we don't want to commit to a schedule we can't keep -- or keep a schedule that doesn't fit the project's long-term needs.
To give us something to plan around, we would like to propose a fixed release schedule. As a six-month release schedule is not something we consider feasible to maintain high-quality standards, we are proposing a fixed eight- month schedule
Not bad, but there is a bit of flexability in being able to adjust the release date. Do we want to give that up?
We have spent a considerable amount of time asking if we should go with a September release for 11.2 and then adopt an eight-month release schedule, or begin with an eight-month release schedule right away. And we came to the conclusion that it's best to adopt the eight-month schedule right away.
A six-month release cycle is interesting because you "only" have to find two months in the year for a release. Eight months makes it slightly more complicated, as you have a rotating schedule, and lose a month in the summer and winter for holidays
I like the rotating month schedule, that way we release at different times of the year.
So, what we're proposing is this -- the next openSUSE release in November 2009, with the next releases in July 2010, March 2011, and so forth:
November 2009: "Fichte" 11.2 July 2010: "Rousseau" 11.3 March 2011: "Voltaire" 12.0 November 2011: "Lessing" 12.1
This gives us a single release in 2009 and 2010, and two releases in 2011. The version names and numbers may change, of course.
Sounds good as far as general time releases. But what's with the names? Is this an internal codename, or something we want to start publicly announcing (instead of version numbers)?
Public releases would happen on the Thursday before the 15th of the month, and the gold master (GM) would be finalized one week prior to that.
Again seems a little strict, I don't see why we can't vary the release date.
We are planning a strict four-week release candidate (RC) phase.
This means that the last chance to change _anything_ but really urgent fixes would be the check-in deadline of RC1, which would be released in week 41 in 2009.
The 4-week RC deadline is nice!
The schedule would leave us with whatever software we have at that point. For example, we'll miss KDE 4.5 for 11.3 or the spring version of GNOME for 12.0. If missing these releases is a problem, let's discuss this _now_.
As we're all aware, trying to get the latest releases of everything in every release isn't successful - see the shaft of KDE 4.1 in 11.0 - but being able to adjust the release based on a release of KDE, GNOME, etc. is useful.
Of course, this doesn't mean we can't publish supported or unsupported addons or updated live CDs with the respective desktops or similar software: We just need people willing to do it.
Why such a late release date? Releasing 11.2 in November has some advantages over releasing in September: - We don't rely on contributions during the summer months that much.
Not complaining or anything, but what exactly does this mean?
- We can easily integrate GNOME 2.28.
Insert smiley face here :-)
- We are more likely to have working drivers for hardware released in early summer is higher. (This is a weak advantage since the summer release of Intel's graphic chips didn't work out with a December release either.) - We simply have more time for everything.
As has been proven with the past release, more time and more testing is better for everyone.
The features we have in mind for 11.2 center around these top features: * Newer and better software, including: - KDE 4.3 - GNOME 2.28, - Linux kernel 2.6.30 or higher * Ext4 - possibly even as the default filesystem. * Provide YaST Web interface for easier remote adminstration. * Netbook support - Offer USB images - possibly even with deployment tool if someone writes it. - Include free drivers necessary for the netbook support. * Officially support live updates - we need way more people to use factory and report problems though.
Live updates?
* Quicker, Faster and more Colourful
Colorful, huh? I guess it's time to reopen the Pixel Pool for art contributions. jimmac, thoughts on this?
OK, I better stop here. This is already a pretty long mail - looking forward to your feedback. The last time we discussed schedules, the feedback was very good - and got us thinking quite a long time. ;)
Thanks Stephan :-) And thanks to the team for making this schedule the most openly planned ever! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org