On Mon, 2008-12-15 at 09:48 -0500, JP Rosevear wrote:

I agree, I think its odd to make a lengthy 10 month schedule and then not add on 2-4 weeks to grab the final version of GNOME. Within 2 months Ubuntu, Fedora and Mandriva will have new releases with a 6-months-newer GNOME.

Good point. If it's not too long of an addition, I would rather see the release be delayed for GNOME.

And it's not *too* lengthy, even delaying 11.2 by a month (an extreme case, it seems to me) would still be a shorter development period than we had for 10.2 -> 10.3 (Dec. 7, 2006 until Oct. 4, 2007)

On Tue, 2008-12-16 at 12:18 +0100, Dirk Müller wrote:

On Monday 15 December 2008, JP Rosevear wrote:

...

I agree, I think its odd to make a lengthy 10 month schedule and then not add on 2-4 weeks to grab the final version of GNOME.

final version? GNOME finally ceases to exist? ;)

I don't see the point, there will always be yet-another-release of major software that we'll miss.

The point is that the original schedule proposal specifically called out wanting to include KDE 4.3 (and OpenOffice - but that was incorrect schedule wise, however with a september release its also back into play) and specifically rejected a release date because of it. So major releases seem to be driving the schedule proposal for now.

I do agree we should shoot for 4.3 if possible as well as KDE 3.5 will be dropped out of the next release and jumping as far ahead as possible to close the feature gap is necessary.

It would make more sense to spend time on incremental improvements of the platform and not sync schedules with the latest desktop gimmick that only 50% of the users use (be it KDE or GNOME or ..). Furthermore those parts are exchangeable, one click and you have a buildservice repository that always ships the latest shiniest KDE.

I think the KDE buildservice is great for testing. I don't think the build service is used by a majority of desktop users though.

I don't understand why a shorter release cycle was dismissed, there was no reason given? How about a release in ~ May, which includes kernel 2.6.28 and gcc 4.4, and then a release around October/November for 11.3? These plans have synergy effects: we can make use of a stable 2.6.28 kernel already for other products, and we can make use of the testing of an intermediate 11.2 release to make sure that 11.3 is stable enough to become synced with the Enterprise Desktop SP1.

Sure - this is why I also suggested we discuss more than just 11.2 at this time.

The openSUSE Build Service good infrastructure to provide the latest desktop to the user. It does not provide good infrastructure to ship the latest kernel/X.org/compiler, because those are not really leaf packages like the desktop is.

Or does the openSUSE GNOME team really prefer to skip a completeGNOME release because 11.2 would only be released autumn next year? And why does the

I don't understand what you are saying here - GNOME would be updated to 2.26 for 11.2 if 2.28 was not feasible.

opinion of the GNOME team matter on the release cycle of a linux distribution?

The downstream openSUSE GNOME team's opinion should matter I hope as part of the community.

Shouldn't we make sure that we ship a newer platform in time so that the desktops can make use of platform features and test and prepare that in the community, offloading all the "the stuff does not compile/work anymore" to the development community?

And what are we doing when the other distros ship their spring release?

Yes, see above, starting to plan more than one release at a time (from a schedule perspective) would be helpful imho.

-JP

2008/12/16 JP Rosevear jpr@novell.com:

On Tue, 2008-12-16 at 12:18 +0100, Dirk Müller wrote:

...

On Monday 15 December 2008, JP Rosevear wrote:

...

It would make more sense to spend time on incremental improvements of the platform and not sync schedules with the latest desktop gimmick that only 50% of the users use (be it KDE or GNOME or ..). Furthermore those parts are exchangeable, one click and you have a buildservice repository that always ships the latest shiniest KDE.

...

I don't understand why a shorter release cycle was dismissed, there was no reason given? How about a release in ~ May, which includes kernel 2.6.28 and gcc 4.4, and then a release around October/November for 11.3?

...

I don't understand why a shorter release cycle was dismissed, there was no reason given? How about a release in ~ May, which includes kernel 2.6.28 and gcc 4.4, and then a release around October/November for 11.3? These plans have synergy effects: we can make use of a stable 2.6.28 kernel already for other products, and we can make use of the testing of an intermediate 11.2 release to make sure that 11.3 is stable enough to become synced with the Enterprise Desktop SP1.

The openSUSE Build Service good infrastructure to provide the latest desktop to the user. It does not provide good infrastructure to ship the latest kernel/X.org/compiler, because those are not really leaf packages like the desktop is.

That's an interesting point. I'd bracket gcc & glibc as the tricky upgrades. The kernel and X has been provided via update rpm's in the past (SuSE 7.X times), why can't they be done by build service, if a bundle containing any system tools that require upgrading is included in the "release set"? I install several different kernel rpm's on anything but play systems, and it's saved pain with a Rescue CD on several occasions.

gcc, updates are usually easy to install for developers, but pointless in OpenSUSE context unless you recompile the system source. Similarly glibc, it has to provide binary compatability for older executuables, but without relinking against it, you're not going to achieve the aim of widespread use.

Now a May release, includes gcc-4.4, kernel 2.6.8; and KDE 4.2 which is at beta stage at present. Which one out of those, will the most end users actually care about?

What improvements make this compelling to end users?

May be the whole big bang release idea where everything gets updated all together is somewhat broken. The big projects the distro packages operate independently.

So how about a more "Tick Tock" based approach, does that provide more flexibility and is it more natual?

X.0 - kernel, glibc, gcc, binutils, base utitlities, filesystems (rest feature stable, bug fixes only) X.1 (KDE) (OOo) - core stuff proven (and stabilised), latest applications X.2 (GNOME) - more application updates (FINAL release goes to retail, upgrade from X.1 & 11.1)

Y.0 - kernel, glibc, gcc Y.1 - (APPLIC perhaps mainly YaST this time) Y.2 - significant kernel release + upgrade of core server daemons Y.3 - Desktop updates (FINAL release goes to retail, with upgrade from Y.2 & X.FINAL)

De-coupling would allow natural follow on releases focussed on getting out the latest, without destabilishing the whole distro. Only some of the teams are under max stress and release pressure at each point. The interim .0, .1 etc releases culminate in a really solid quality retail distribution. Upgrading from one release version to the next, is a more incremental step.

I think the KDE buildservice is great for testing. I don't think the build service is used by a majority of desktop users though.

That seems like an area, which could be developed. Some sort of "Policy" wizard that then allows the admin to be notified of package upgrade possibilities.

2009/1/5 Gerald Pfeifer gp@novell.com:

On Tue, 16 Dec 2008, Rob OpenSuSE wrote:

...

So how about a more "Tick Tock" based approach, does that provide more flexibility and is it more natual?

X.0 - kernel, glibc, gcc, binutils, base utitlities, filesystems (rest feature stable, bug fixes only) X.1 (KDE) (OOo) - core stuff proven (and stabilised), latest applications X.2 (GNOME) - more application updates (FINAL release goes to retail, upgrade from X.1 & 11.1)

That would work best if upstream projects would align their releases with this schedule. If not, we might end up being woefully behind the curve in key areas, I'm afraid.

(Within any given release cycle, having such a staged approach at least as a goal certainly makes sense, and we have been doing this to some extent.)

Tried to illustrate a point simply and clearly, choosing suggested point releases based on the previous discussion. No intention to set in stone things like a total freeze on gcc, without incorporating bug fix point releases. Or preventing any kernel updates.

There's not really a need for alignment, if you have release managers, making informed decisions based on the cost/benefit analysis of updating a version. And falling "woefully behind the curve" would be a strong argument for change.

I see the kernel as being the main problem area there, where new hardware support is required, or changes cause a regression. For instance since 2.6.18 when libata/pata_ was introduced as "experimental", there's been drivers which consistently have problems. These tended to go unfixed upstream, as hardware with the problem generates a report, but on a production system, it uses a workround (like the older IDE ATA drivers), hardwares replaced, or machine rolls back to previous working release.

Really I'm arguing for more minor releases, with smaller better focussed changes, done in a way that does get used, so that the FINAL retail release is of higher quality.

Once you've been burned badly, with a 'main' release with too much stuff broken, so you could not even make clear bug reports, it acts as a huge disincentive to giving up more time on testing. The natural inclination is to avoid breaking things by experimentation.

2009/1/7 Gerald Pfeifer gp@novell.com:

On Tue, 6 Jan 2009, Rob OpenSuSE wrote:

...

Really I'm arguing for more minor releases, with smaller better focussed changes, done in a way that does get used, so that the FINAL retail release is of higher quality.

Would these minor releases be true releases, or more like milestones on the way to a true release? For example, once .2 has been released, will there still be security updates for .1 or will users be asked to move to .2?

I'd be ruthless, if you install .0, .1 then you *MUST* online update (or if absolutely necessary do a YaST upgrade to get to .2) if you want any form of support.

Perhaps 12.0.0, 12.0.1, 12.0.2 would be more accurate, but these days marketing seems to prefer regular major version changes.

Traditionally SuSE version numbers have been effectively meaningless. Having an annual major version bump, after the development phase of cycle, would keep openSUSE on a higher major version than Ubuntu however, which might be a useful side benefit. Having 3 or 4 minor version increments, every 8 months, and then upping the major version will fall behind the years eventually. ( I used SuSE 6.1 in '99, and am only at 11.1 in '08 now )

Perhaps it will be beneficial (for the sake of this discussion) to separate the question of naming from the contents, since numbers like x.1 or terms like Beta have certain connotations.

My feeling is that openSUSE Betas generally have not been more stable than Alphas, and RCs not necessarily more so than Betas. One way to combine this with what I _think_ you are proposing is to do, say, a mini-release (call it milestone or whatever) every 2, 3, or 4 months that brings a succint set of changes and has a _short_ stabilization phase, and then do a full release every three, four such mini-releases.

Only full releases will see security updates for 18-24 months, users of mini-releases will be asked to move to the next mini-release (which is still more stability than FACTORY provides today). Full launching happens for the full release, but we'll certainly want to also be a bit vocal about mini-releases.

Is this in line with what you are thinking, a sensible variation thereof, or quite something different?

You are right. It seems attempts to explain and discuss this seem to founder, because of pre-conceptions associated with the words. What you propose there, seems to be inline with ideas that I've tried to explore in the discussions.

Incidentally I stumbled on this piece, http://derstandard.at/?id=3413801&_artikelIndex=1 which suggests it's an issue for other distro's to, even with an apparently larger user base.

Shuttleworth discussing a rocky Ubuntu 8.04 LTS - "So we didn't see a sufficient level of beta-testing during the test-period and many bugs are only filed when the release has already been made. So one option that we considered was: "Let's not call 8.04 the LTS, let's call 8.04.1 the LTS", so many people would upgrade who wouldn't use a beta and you get better feedback. So that's something we might do differently with the next LTS. "

Yesterday, I actually wished that when the 11.2 proposed schedule discussion was started, that I'd responded with something like. "11.2 should be released in March, it should contain KDE 4.2, and bug fixes to 11.1; basically it should be 11.1 done right.

As it seems this is a common problem, it seems rather pointless to freeze the GM's with so many end users facing installation blocking problems (and if they do install, a whole load of known but unfixed regressions). And it was those involved most with the release, who originally aired points about shortage of testers and such. Other Novell employees have commented on lack of resources.

That sounds very much like a reason to change, and a longer cycle was done with 10.3, and that still needed a huge number of updates post-release. So as it stands in Zonker's news item release plan, why would 11.2 in autumn be any different?

mini-release (call it milestone or whatever) every 2, 3, or 4 months that brings a succint set of changes and has a _short_ stabilization phase, and then do a full release every three, four such mini-releases.

That would appear to solve the problem of falling behind the curve of KDE, GNOME, Go-OO and the kernel, and any other noteworthy hotstuff & coolness. Assuming, that a goal at the end of the series is stabilised code for SLE, then you can limit the large internal developments to a merge window in Q1/Q2 in year say, with an increasing burden of 'proof' required as the Major release approaches in Q4.

It would also permit, releasing with beta test versions, like KDE 4.2 for 11.1 (rather than 4.1.3 + backports), or as in the Shuttleworth example going with the clearly superior Firefox 3, rather than being lumbered with Firefox 2 for 2 years.

My other main suggestion was to reward early adoption by online update, so that security patches only need developing for same number of kernels, OpenSSH and so forth as now.

So in effect development goes on :

Factory : the very latest in packages, no guarantees -- Debian "experimental" Current : bleeding edge, latest "mini-release" plus updates. Previous mini-releases updated live online if possible, or via an upgrade procedure with YaST booting from ISO. - Debian "unstable" Final Release : the stabilised product, that is fit for box sets, and paid support by easy migration to SLE

Something like that, has a chance to build a community of beta testers, around an evolving release, which would actually run on real hardware.

So to summarise :

User Benefits : Less installing from scratch. A choice of stability, or current software. More involvement with the community distro. Fewer used versions (because of online updates) but better supported. Hope for higher quality in future eg) kernel driver regressions more likely to get back upstream in timely manner.

Developer Benefits : Wider User Base, that grows with time as Full releases stabilise Getting usuable code out earlier, more time for real user Feedback Significant applications updates go onto a known base. Similarly core changes, can occur without having a load of unstable application changes as well. Fewer package versions to support (because "sick" versions, can be force upgraded) Less pressure to rush and opportunity to include "solid" beta's if it makes sense to online update later

Am Dienstag, 16. Dezember 2008 12:18:44 schrieb Dirk Müller:

I don't understand why a shorter release cycle was dismissed, there was no reason given? How about a release in ~ May, which includes kernel 2.6.28 and gcc 4.4, and then a release around October/November for 11.3? These plans have synergy effects: we can make use of a stable 2.6.28 kernel already for other products, and we can make use of the testing of an intermediate 11.2 release to make sure that 11.3 is stable enough to become synced with the Enterprise Desktop SP1.

Actually many complained that 11.1 had a too short release cycle - so they did not really start testing because they hardly finished their 11.0 polishing and I guess that's right for many. And if you go with a may release with many developers having prolonged christmas holidays and ask for an extended RC phase to stabilize and translate, this gives very little time over a kernel and a gcc update. Does pretty hard to sell to users to me.

Greetings, Stephan

On Tue, 2008-12-16 at 20:03 +0100, Stephan Kulow wrote:

Actually many complained that 11.1 had a too short release cycle - so they did not really start testing because they hardly finished their 11.0 polishing and I guess that's right for many. And if you go with a may release with many developers having prolonged christmas holidays and ask for an extended RC phase to stabilize and translate, this gives very little time over a kernel and a gcc update. Does pretty hard to sell to users to me.

I agree with them. I tend to prefer longer release times, particularly from a testing (some people like to use their shiny new release before they go bug hunting in the next one ;-)), and from a marketing perspective (2 to 3 releases a year, every year gets tedious to manage, and overwhelms users).

I think the current openSUSE schedule (which has been described to me as "3 releases over a period of two years", is that about right?) is a good pace.

"Rajko M." rmatov101@charter.net writes:

[...] It is getting hard to follow 6 months release cycle. I barely had time to see 11.0 and it is already candidate for deletion.

I hear on the other hand also suggestions for openSUSE to go on a planned 6-month release cycle like Ubuntu and Fedora does - and release say every November and May.

Is that something we should do for the future (after 11.2) - or what is the best way to do releases in general?

Andreas

2008/12/17 Bryen suserocks@bryen.com:

On Wed, 2008-12-17 at 07:57 +0100, Andreas Jaeger wrote:

...

"Rajko M." rmatov101@charter.net writes:

...

It is getting hard to follow 6 months release cycle. I barely had time to see 11.0 and it is already candidate for deletion.

I hear on the other hand also suggestions for openSUSE to go on a planned 6-month release cycle like Ubuntu and Fedora does - and release say every November and May.

What I'm observing more of in this thread, and hearing from people talking directly to me, is that it isn't so much the time frame for development in as much as the full utilization of each phase. Less testing on alpha, more testing on RC as an example of a rather lop-sided effect we've had. I think the focus of discussion should be more about how we can improve the experience, thus making people likelier to participate earlier on.

Then perhaps rather than just "Factory" aka "unstable", add "testing" and "stable" rather than fixed releases; so most of the community upgrade via small steps constantly; as they should do for security fixes. The stable release could presumably be updated by the SP1, SP2 type method, giving magazines and disk emporiums, something useful to provide to those with poor net connections.

May be for the interim versions, made available for testing, some indication of "solidity" would help, based on the underlying technical changes made, and feedback from the "Factory".

On Tue 06 Jan 2009 02:04:29 NZDT +1300, Gerald Pfeifer wrote:

...

I think the focus of discussion should be more about how we can improve the experience, thus making people likelier to participate earlier on.

Fully agreed.

Here are reasons why I don't participate as much as I'd like to:

* Installation is totally broken. When I have a weekend to do testing, I can install beta X during a third of that, and then play with applications for the rest of it, thus generating useful (and for user acceptance important) bug reports. If after a dreadful installation experience I can foresee that I will be spending the rest of the weekend trying to get the system to a state where I can finally start an application, the period of beta X is over before I've found enough non-existant time during the week to do useful testing.

So my metrics for the length of the beta period is the length of time a *testable* beta is available. So if a release doesn't install and it takes 2 weeks to fix (or six weeks, as the case may be), then extend following milestones by that much, or consider the beta period shortened.

This is the main reason I didn't file any reports for 11.1.

* Lack of test environment. I need a stable and dependable computer for daily use. I don't have the reasources to be an identical new computer just for testing. The old computer(s) are inefficient, and nobody cares about their driver-related bugs. It would really help if there were good rundowns of how to test the current beta on the previous(!) (preferably two) stable releases - what the options are, and how to use them.

I tried vmware once, but it wasted more time on vmware itself than what it was worth. The beta guest didn't run properly either, and just forget about any time-related software. There was always one more peice of whatnot to install in the guest which wasn't readily available and would have taken heaps of time to obtain. Too inefficient to do useful beta testing with.

Running a risk of being forced to say "no I can't do this for you right now because my Linux is broken" is not an option when I keep saying to people they should try Linux over XYZ because things just work today, tomorrow, and the day after.

Of course it's also my fault that I haven't put together that wiki page.

* A large part why I participate in testing is so that I end up with a system which works reliably and is reasonably bug free in the areas I use myself. Finding that bugs I reported are still present in GM is disillusioning. For example I have given up on counting the years I've entered the same bugs now for RAID1 use on a desktop machine (IMHO it's nuts not to use it, yet it doesn't work out of the box unless you know what you're doing).

If each release has 5 bugs fixed and 3 new ones (and sometimes 3 fixed, 5 new) then it's too much like Microsoft. If my efforts make a difference here I'd be more motivated.

* Nothing to do with SUSE: my weekends are too full with everything else... ;)

Volker

Onsdag 17 december 2008 07:57:49 skrev Andreas Jaeger:

I hear on the other hand also suggestions for openSUSE to go on a planned 6-month release cycle like Ubuntu and Fedora does - and release say every November and May.

Is that something we should do for the future (after 11.2) - or what is the best way to do releases in general?

I'm for the 7-9 month schedule.

Especially if short release cycles are supposed to be as chaotic as the last one, and leading to a similarly Fedora'esque release quality. But maybe shorter release cycles with smaller changes would lead to better quality - still not clear to me what went wrong this time.

On Wed, 2008-12-17 at 07:57 +0100, Andreas Jaeger wrote:

"Rajko M." rmatov101@charter.net writes:

...

[...] It is getting hard to follow 6 months release cycle. I barely had time to see 11.0 and it is already candidate for deletion.

I hear on the other hand also suggestions for openSUSE to go on a planned 6-month release cycle like Ubuntu and Fedora does - and release say every November and May.

Is that something we should do for the future (after 11.2) - or what is the best way to do releases in general?

I'm all for the "release often" bit of it, especially if we're going to keep our current structure were we combine everything on one DVD. The reason for that is mostly due to more hardware supported by the kernel. If we don't release a new version of openSUSE every ~6 months, we would/should come up with a new structure, such as the one I proposed already (where we have a base DVD that can be released often and have the DE environments as add-ons and they would be released whenever there is a new version available).

Cheers, Magnus

On Wednesday 17 December 2008 12:57:49 am Andreas Jaeger wrote:

"Rajko M." rmatov101@charter.net writes:

...

[...] It is getting hard to follow 6 months release cycle. I barely had time to see 11.0 and it is already candidate for deletion.

I hear on the other hand also suggestions for openSUSE to go on a planned 6-month release cycle like Ubuntu and Fedora does - and release say every November and May.

Is that something we should do for the future (after 11.2) - or what is the best way to do releases in general?

Whatever will be release cycle length the load should be proportional to available number of people that will test it and later on maintian it.

It would be good to try testing focused on the part of the system. Bootloader, kernel, X and desktop are important to everyone. Focusing all testers on fewer important parts will create reliable base system. With that system set in low speed everybody can go and test favorite applications.

Upstream development will for sure benefit from more testers and that as a common interest can help to synchronize major projects, with smaller following the trend.

On Tuesday 16 December 2008, Stephan Kulow wrote:

Actually many complained that 11.1 had a too short release cycle - so they did not really start testing because they hardly finished their 11.0 polishing and I guess that's right for many. And if you go with a may release with many developers having prolonged christmas holidays and ask for an extended RC phase to stabilize and translate, this gives very little time over a kernel and a gcc update. Does pretty hard to sell to users to me.

Well, perhaps we shouldn't focus so much on "selling openSUSE" but rather on selling the addons of openSUSE, namely a well-maintained contrib repository, various build service projects and make it easy for them to be installed in parallel on openSUSE and the community support around it.

Thats where the openSUSE as a product looses a bit of focus and rather provides a regularly updated base system (including new hardware enablement etc), and the focus is shifted towards openSUSE as a community project.

As an example: I recently bought a new notebook and 11.0 didn't even boot on it upon first start, so I had to start installing it with a horribly broken 11.1 Beta in order to get something out of it at all. I would have preferred a 11.1 that was just as good as 11.0 but had the newer kernel etc which I needed for being able to complete installation. There are plans of various chipset vendors to release new hardware platforms before mid of 2009, and possibly 11.1 will again no longer boot on them and will need a newer base system.

Greetings, Dirk

On Monday 15 December 2008, Dominique Leuenberger wrote:

...

...

...

On 12/15/2008 at 14:43, Michael Loeffler michl@novell.com wrote:

First we talked about July '09 release to come close to an 8 months release cycle. But KDE 4.3 is scheduled for release on June 30th and

probably an OpenOffice.org release will be out end of June as well -

both wouldn't make it into a July openSUSE 11.2. Therfor we're now

It's like always with release dates: getting in 'sync' with upstream projects is close to impossible, except if they would all adjust.

So we postpone 11.2 for 2 month in order to get KDE 4.3 in... sounds actually quiet fair.

And just to let you know: by the typical 6 month cycle, just in September will most likely be also Gnome 2.28 ;) So we just miss the addition of hte greatest / best of gnome...

I just checked with aj on Gnome. And my evaluation timewise with implementing Gnome is too long. We should be able to get Gnome in 11.2 if we have the Gnome GM with last openSUSE Beta version or even RC1 might be possible. But the latter needs to be confirmed by our Gnome colleagues JP and Vincent.

but you see what I want to say with this anyhow.

So let's get the discussion going on and I'll do some reschedulung to get latest Gnome in with 11.2.

M

Dominique

On Monday 15 December 2008, JP Rosevear wrote:

On Mon, 2008-12-15 at 14:43 +0100, Michael Loeffler wrote:

...

Moin,

openSUSE 11.1 is almost out of the door and we (coolo, aj, zonker and myself) had some discussion about the release date for openSUSE 11.2.

First we talked about July '09 release to come close to an 8 months release cycle. But KDE 4.3 is scheduled for release on June 30th and probably an OpenOffice.org release will be out end of June as well -

It is unlikely there will be any major OpenOffice.org update released at the end of June - the release would be 3.1.1. 3.1 is scheduled for March 25 currently.

...

both wouldn't make it into a July openSUSE 11.2. Therfor we're now thinking about a September release. Beside of getting the most current OpenOffice and KDE in thhis would even have one additional upside. It probably would be just in front of our openSUSE conference. So the conference could be used for very a focused openSUSE 11.3 planning. But it has its downside as well. Finalization of the release would happen during the summer holiday season. To address this we we added one Beta to stretch the development time a bit.

Here's what we're talking about:

2009-02-05 openSUSE 11.2 Alpha 0

Nearly 2 months to alpha 0 seems like a long time - is this simply an infrastructure issue because of SLE 11?

There are 2 things. SLE 11 finalization phase which will keep many of the internal guys busy. And the vacation season till mid of January.

What will the state of Factory be during this time?

Factory is ongoing synced out.

M

-JP

On Monday 15 December 2008 22:57:07 Magnus Boman wrote:

On Mon, 2008-12-15 at 09:46 -0500, JP Rosevear wrote:

...

On Mon, 2008-12-15 at 14:43 +0100, Michael Loeffler wrote:

...

Moin,

openSUSE 11.1 is almost out of the door and we (coolo, aj, zonker and myself) had some discussion about the release date for openSUSE 11.2.

First we talked about July '09 release to come close to an 8 months release cycle. But KDE 4.3 is scheduled for release on June 30th and probably an OpenOffice.org release will be out end of June as well -

It is unlikely there will be any major OpenOffice.org update released at the end of June - the release would be 3.1.1. 3.1 is scheduled for March 25 currently.

...

both wouldn't make it into a July openSUSE 11.2. Therfor we're now thinking about a September release. Beside of getting the most current OpenOffice and KDE in thhis would even have one additional upside. It probably would be just in front of our openSUSE conference. So the conference could be used for very a focused openSUSE 11.3 planning. But it has its downside as well. Finalization of the release would happen during the summer holiday season. To address this we we added one Beta to stretch the development time a bit.

Here's what we're talking about:

2009-02-05 openSUSE 11.2 Alpha 0

Nearly 2 months to alpha 0 seems like a long time - is this simply an infrastructure issue because of SLE 11?

I actually don't mind it being 2 months. In the past, when we released Alpha0, it's basically been the last released openSUSE plus a few updates.

Yes, that is to be expected for parts we actively develop - people are busy until release with fixing bugs, so they start with a new stuff only shortly after release (and vacations and ...).

What you see though is package version updates.

Stano

On Tue, 2008-12-16 at 12:00 +0100, Dirk Müller wrote:

Perhaps because some people also want to do vacation or reasonable development somewhen during the year? ;)

I don't think it makes sense to fill every month with opensuse alphas just because we can. if there has to be some time where changes are actually being done instead of being in release-mode all the time.

I agree wholeheartedly.

Il giorno lun, 15/12/2008 alle 09.57 -0500, Joe 'Zonker' Brockmeier ha scritto:

As others have said - I have some reservations about releasing in September and just missing a GNOME release.

I know that syncs badly with the conference, but I think GNOME is important enough to go ahead and wait for it. Why have such a lengthy release cycle and then just miss GNOME?

I tend to think it is a lot better to have old but working GNOME, rather than pushing the new version in at the last minute. It did not work in the past, and I don't see how it should be different this time.

Regards, A.

On Mon, 2008-12-15 at 19:44 +0100, jdd wrote:

Alberto Passalacqua a écrit :

...

I tend to think it is a lot better to have old but working GNOME, rather than pushing the new version in at the last minute. It did not work in the past, and I don't see how it should be different this time.

exactly.

This is only partially true, GNOME will be feature frozen before the end of July and would have regular updates throughout a development cycle.

-JP

Am Montag, 15. Dezember 2008 21:38:36 schrieb JP Rosevear:

On Mon, 2008-12-15 at 19:44 +0100, jdd wrote:

...

Alberto Passalacqua a écrit :

...

I tend to think it is a lot better to have old but working GNOME, rather than pushing the new version in at the last minute. It did not work in the past, and I don't see how it should be different this time.

exactly.

This is only partially true, GNOME will be feature frozen before the end of July and would have regular updates throughout a development cycle.

Sorry, but how many 10.3 online updates you had to push because the final GNOME was broken? We need to have the last GNOME GM-4 weeks. No discussion there. If we delay GM or skip autumn GNOME I don't mind.

Greetings, Stephan

Am Dienstag, 16. Dezember 2008 22:28:33 schrieb Magnus Boman:

Thought it might be worth mentioning it.

Limiting openSUSE to GNOME or KDE is just wrong. Interesting idea though.

Greetings, Stephan

On Tuesday 16 of December 2008 23:28:41 Magnus Boman wrote:

On Tue, 2008-12-16 at 22:44 +0100, Stephan Kulow wrote:

...

Am Dienstag, 16. Dezember 2008 22:28:33 schrieb Magnus Boman:

...

Thought it might be worth mentioning it.

Limiting openSUSE to GNOME or KDE is just wrong. Interesting idea though.

Hmm, would it be possible to have a base openSUSE system, and have GNOME/KDE as addons? It wouldn't be *that* much of a difference compared to the LiveCD's?

Well, technically spoken, yes. I don't think many users would like this approach, installing from a single DVD is just too comfortable.

On the other hand, we might consider providing up-to-date desktop environments as add-on products during the life cycle of the distro (basically make an add-on from factory repo after new KDE/GNOME/whatever gets released and stabilized).

Jiri

On Thursday 18 December 2008 01:38:59 Rajko M. wrote:

On Wednesday 17 December 2008 02:13:42 am Jiri Srain wrote:

...

On Tuesday 16 of December 2008 23:28:41 Magnus Boman wrote:

...

On Tue, 2008-12-16 at 22:44 +0100, Stephan Kulow wrote:

...

Am Dienstag, 16. Dezember 2008 22:28:33 schrieb Magnus Boman:

...

Thought it might be worth mentioning it.

Limiting openSUSE to GNOME or KDE is just wrong. Interesting idea though.

Hmm, would it be possible to have a base openSUSE system, and have GNOME/KDE as addons? It wouldn't be *that* much of a difference compared to the LiveCD's?

Well, technically spoken, yes. I don't think many users would like this approach, installing from a single DVD is just too comfortable.

On the other hand, we might consider providing up-to-date desktop environments as add-on products during the life cycle of the distro (basically make an add-on from factory repo after new KDE/GNOME/whatever gets released and stabilized).

Jiri

That's good idea in many ways:

• base distro would have to sync with smaller number of upstream projects
• the addon desktop CDs can be tested out of sync with main release
• current problems with last minute inclusion or time spent on backports

are out for good

• users that depend on physical media will get opportunity to have the

newest desktop without much work to download oBS repository

Is there any adverse effects?

The problem is that you need to explain to users how to use addon desktop CDs. And this will become a problem, I'm pretty sure. There is stuff like media changing during installation, not forgetting to add it, also we would need to test quite a bit more scenarios to make sure the experience is smooth.

Keep in mind that 'everything is right there' is one of the most noted advantages of openSUSE compared to other distros.

Stano

Am Donnerstag, 18. Dezember 2008 09:10:40 schrieb Rastislav Krupanský:

Hi everyone,

If i can say something. I suppose we could wait for a new openSUSE survey, as we did in August - http://news.opensuse.org/2008/08/21/last-call-for-opensuse-survey/ There should be a question about schedule - how should developement period take, or how long development schedule do you wish - whether 6,8,9... months etc. Result could show which period plan would be ideal for most users/developers.

Btw, i also prefer longer release time, for example 8 or 9 months. 6 months is too short.

Oh, if you ask users they will want every 5 months a new release with tons of new features that works exactly like the release before. It's not so interesting what users prefer, this is something that is important for the developing community. My person guess is that users will accept any schedule as long as the outcoming release is good. And this is something we need to find out: how much time do we need to be good.

Greetings, Stephan

2008/12/18 Stephan Kulow coolo@novell.com:

Am Donnerstag, 18. Dezember 2008 09:10:40 schrieb Rastislav Krupanský:

...

Hi everyone,

If i can say something. I suppose we could wait for a new openSUSE survey, as we did in August - http://news.opensuse.org/2008/08/21/last-call-for-opensuse-survey/ There should be a question about schedule - how should developement period take, or how long development schedule do you wish - whether 6,8,9... months etc. Result could show which period plan would be ideal for most users/developers.

Btw, i also prefer longer release time, for example 8 or 9 months. 6 months is too short.

Oh, if you ask users they will want every 5 months a new release with tons of new features that works exactly like the release before. It's not so interesting what users prefer, this is something that is important for the developing community. My person guess is that users will accept any schedule as long as the outcoming release is good. And this is something we need to find out: how much time do we need to be good.

If we're voting then I much prefer the longer ~10month+ release cycle length.

With only 6 months you're in feature freeze for half the year. Once you add on time to do fixes to released products, time to have a holiday, there's only about a month or so of time to do actual development between freezes. Then it's difficult to actually develop against it in that time (alpha) because there's a mad rush of changes throughout the entire stack which keep breaking your software.

Longer release cycle has other benefits too. Less work for security team with fewer versions to support concurrently; Ditto third party packagers and ISVs; How many people really want to reinstall their OS every 6 months. and so on.

Of course there's the argument that people always want the bleeding edge, but I think we cater for most of those quite well with unofficial packages in the buildservice and such. Changes spread out more throughout the year might also help make factory more stable for those who really want the latest, more people running factory can only be a good thing.

-- Benjamin Weber

On Fri, 2008-12-19 at 01:10 -0500, Justin Haygood wrote:

On Thu, 2008-12-18 at 19:50 +0000, Benji Weber wrote:

...

If we're voting then I much prefer the longer ~10month+ release cycle length.

Me as well.

Having the longer release cycle has the following benefits:

• Longer development sprints = more whiz-bang features per release (at

the expense of fewer releases per time period). Plus, if you do finalize on a version and a newer version will be out soon, you could always backport the more stable new features if they are easily separable.

• More stable packages (since you have more time to get fixed upstream

packages, and to find and patch any bugs in packages, and to backport fixes from newer upstream releases after the upstream version to track has been finalized). This is one of the reasons I like openSUSE.. it has the benefits of a stable platform with a "fast" (fast enough) development cycle.

• More time for openSUSE developers to work on creating things as

opposed to just integration of upstream. After all, if I wanted a release that looks like upstream, I'd be using Foresight ;).

--Justin

Absolutely.

On Saturday 20 December 2008 11:47:20 Markus wrote:

Am Donnerstag 18 Dezember 2008 20:50:55 schrieb Benji Weber:

...

If we're voting then I much prefer the longer ~10month+ release cycle length.

Madriva switched away from a 12 months cycle after a community survey because it was considered too long. IMHO the release cycle should not exceed 10 months.

There are IMO the following ways to release a distribution: * on a strict regular schedule. This could be 6 months like Ubuntu or the 12 months as proposed. I would not propose a strict schedule with another number of months since that would lead again to a non-regular schedule * on a non-regular schedule - this is what we're doing right now where we aim for 8 months but achieve 6-10 months depending on other factors

Andreas

On Thu, 18 Dec 2008, Benji Weber wrote:

Longer release cycle has other benefits too. Less work for security team with fewer versions to support concurrently;

Only under the assumption that the two years of security update are going to stay, versus two releases + two months (for example).

Ditto third party packagers and ISVs

ISVs and openSUSE is not exactly in focus. Even a year or two are short as far as ISVs are concerned.

Gerald

On Thursday 18 December 2008 01:11:08 am Stanislav Visnovsky wrote:

The problem is that you need to explain to users how to use addon desktop CDs. And this will become a problem, I'm pretty sure. There is stuff like media changing during installation, not forgetting to add it, also we would need to test quite a bit more scenarios to make sure the experience is smooth.

That is smaller problem then to describe how to use oBS repo if repo has no 1-click link.

One link on fresh installed desktop "Additional software" will not need explanation, it will be call for click.

It seems that whole idea is to have small base that is good tested, and addons that are pretty much the same as patterns, or few patterns. Rounded selections of software needed for certain purpose. Though, for this purpose base is not necessarily the same as base pattern.

Keep in mind that 'everything is right there' is one of the most noted advantages of openSUSE compared to other distros.

Yes, and with every release is even more right :-)

Volker Kuhlmann a écrit :

In case of OpenOffice wouldn't it be more or less trivial to detach the OO release completely from the desktop/distro release? Unlike the desktop software without which a desktop computer doesn't go, neither OO nor the desktop depend on each other. One less upstream date to worry about.

what we should absolutely do is separate the distro in important chunks:

* kernel * console only system * X * kde / gnome / whatever

...

that is, if the kernel is buggy and don't boot, having openoffice is absolutely pointless :-(

if gnome is good, we can test it even if kde is not...

that could make the devs ask for specific tests (like they do sometie, but more planned)

jdd

On Wed 17 Dec 2008 10:44:08 NZDT +1300, Stephan Kulow wrote:

Limiting openSUSE to GNOME or KDE is just wrong. Interesting idea though.

Not new, Ubuntu has always been doing that - except they treat KDE as something between an afterthought and couldn't-care-less.

Ideally I would like to see both KDE and Gnome in a well-rounded distribution, but with a priority on KDE, for two reasons: I personally find Gnomes outside the garden seriously infuriating (enough to have to put up with that with gimp, OO and firefox, thanks SUSE for knocking that at least into usable shape!), and, by way of response to JPR's "what about Fedora, Ubuntu, Mandriva shipping the latest Gnome 2 weeks after", those who like to have the latest and greatest Gnome should use one of the above. As there isn't a distribution with an emphasis on KDE I would see this as a distinguishing feature. And by "emphasis on KDE" I don't mean treating Gnome as secondary, but if it's impossible to align with both KDE and Gnome release dates, to align with the KDE ones.

Volker

2008/12/16 Kevin Dupuy kevin.dupuy@opensuse.org:

On Wed, 2008-12-17 at 08:28 +1100, Magnus Boman wrote:

...

If we do DE based releases, problem would be solved (ie, release openSUSE 11.2, KDE Edition when the KDE Devs/Community feels it's ready, and likewise for GNOME). What it might mean is that this time around, the KDE edition is released a month or two prior to the GNOME edition.

But at that point, we might as well just choose one desktop environment as the default (which I'm NOT advocating, BTW). I don't know if the mirrors will come after ya, but I have an idea the Marketing team will ;-). Seriously, managing two different versions of the same "version" being released would confuse even some Linux users :-)

So bump the number, and make the new rpm's installable via update. If the core base is the same, then you have more users running the same major version, those who want 'stability' could stay with the final version of the previous release, those who love to be current, can track the new software to get to the very latest minor release (and/or pre-release test betas of new versions via build service repository if that exposure is deemed desirable).

Having 10.2/10.3/11.0 and then 10.3/11.0/11.1 must be as hard to support, as something like 11.3 (Final KDE4.3, GNOME 2.28, OOo 3.1.1) plus 12.x which is 'current' with the most recent release made When applications lag the infrastructural core of the distro, at least they're known quantities, and already have to be supported in the last final release.

Isn't the point to maximise the user base, so that SLED & SLES are fairly bullet proof, and likely end-user issues have already been experienced?.

On Tuesday 16 December 2008, JP Rosevear wrote:

...

Sorry, but how many 10.3 online updates you had to push because the final GNOME was broken? We need to have the last GNOME GM-4 weeks. No discussion there. If we delay GM or skip autumn GNOME I don't mind.

I don't know now - how many?

there were around 20 updates of gnome related packages within 4 months after 10.3 release. Thats too many.

Greetings, Dirk

On Monday 05 January 2009, JP Rosevear wrote:

...

there were around 20 updates of gnome related packages within 4 months after 10.3 release. Thats too many.

Ok - and is the only factor driving the "too many" designation resource constraints?

Well, your question sounds to me like "Did he die because his heart stopped working?". Of course, assuming infinite amount of ressources we can do everything.

The "too many" was more expressing the fuzzy feeling of why people think the 10.3 model was bad (shipping many updates shortly after release doesn't give a good impression of the product).

Greetings, Dirk

Can I suggest that the discussion is caused by a difference between the development processes and the delivery.

Combining a development environment that is open source where there are no absolute deadlines with a delivery process that is commercial and based upon marketing plans, industrial (contracted) production and store sales plans will inevitable that there will be mismatches.

As openSuSe will be open source, it is clear that the only solution is to change the delivery mechanism. The question is how.

David

Am Montag 05 Januar 2009 schrieb JP Rosevear:

On Mon, 2009-01-05 at 12:23 +0100, Dirk Müller wrote:

...

On Tuesday 16 December 2008, JP Rosevear wrote:

...

...

Sorry, but how many 10.3 online updates you had to push because the final GNOME was broken? We need to have the last GNOME GM-4 weeks. No discussion there. If we delay GM or skip autumn GNOME I don't mind.

I don't know now - how many?

there were around 20 updates of gnome related packages within 4 months after 10.3 release. Thats too many.

Ok - and is the only factor driving the "too many" designation resource constraints?

LiveCD being buggy would be another I think.

Greetings, Stephan

Hi,

Le mercredi 17 décembre 2008, à 07:50 +0100, Andreas Jaeger a écrit :

Stephan Kulow coolo@novell.com writes:

...

Sorry, but how many 10.3 online updates you had to push because the final GNOME was broken? We need to have the last GNOME GM-4 weeks. No discussion there. If we delay GM or skip autumn GNOME I don't mind.

Vincent, JP: What is the expected GNOME release day? Is it early or late September? Anything concrete yet?

We don't have a schedule for GNOME 2.28 yet, since we usually prepare it a few weeks before we start the development cycle. This means we'll have the GNOME 2.28 schedule around February/March. But it's highly probably that 2.28.0 would be officially out on September 23rd (other likely possibilities are September 16th and 30th, but 23rd would be the logical date based on the 2.24 development cycle).

Sorry -- I couldn't participate to the thread earlier since I'm travelling. I've a very bad internet connection, but I'll try to send a few comments after reading more of the thread.

Vincent

2008/12/15 jdd jdd@dodin.org:

Alberto Passalacqua a écrit :

what will you do if kde reshedule?

If KDE reschedules, then 4.2 + some 'back ported' features sounds good to me; with 3.5.10 as an option like in 11.1. KDE has been at a difficult point in the software life cycle, whist I actually enjoyed basic use of 11.1's KDE4, I suspect that KDE 3.5.10 will remain a popular choice. The 4.2 release has been getting better reviews, and I noticed OpenSUSE had included some of the 'new' features in 4.1.3. 4.3 is going to be the crunch release for me, it either makes it by then, or breaks for me (XFCE or LXDE seem like the most promising replacements). So I hope it makes sense, remains fast, becomes very solid and avoids emasculation at hands of "Usability Experts".

there will *always* be a *breaking new* great application needing to wait some more weeks...

Yes, whilst the Build service and 1 Click install do really change the landscape, from the old days of waiting on box sets.

However OpenSUSE needs to maintain interest, and not everyone has a fast net connection; so something to get reviewed, appear on Magazine covers, for cheap disk emporiums to send out, and to put in the retail box set makes sense.

May be Build service labels like "X::Stable", "X::Latest" could be leveraged in the post-install process, presenting a selection of unstable, latest & greatest software for those with decent net connections and tolerance for frequent updates?

Joe 'Zonker' Brockmeier a écrit :

On Mon, Dec 15, 2008 at 1:44 PM, jdd jdd@dodin.org wrote:

...

there will *always* be a *breaking new* great application needing to wait some more weeks...

To keep it in perspective, we're not talking about *an application*, we're talking about a desktop environment that is made up of a slew of other applications.

not only: we spoke also of openoffice, why not firefox and thunderbird? why not sync with Mandriva, Ubunto or Debian :-)?

anyway we have no way to know what others are to do and we shouldn't bother.

Let's use our optimal release cycle and let the *build service* do what it does very well. The build service is the thing we have to rely on for latest product.

it's even easy to have new kde, gnome, openoffice... whatever available on cd through build service for people needing a cd, not even necessary to mirror these cd's (they are usefull, but only for a small part of our users)

jdd

Zonker,

On Mon, 2008-12-15 at 17:45 -0500, Joe 'Zonker' Brockmeier wrote:

On Mon, Dec 15, 2008 at 5:26 PM, jdd jdd@dodin.org wrote:

...

it's even easy to have new kde, gnome, openoffice... whatever available on cd through build service for people needing a cd, not even necessary to mirror these cd's (they are usefull, but only for a small part of our users)

Not necessarily. For instance - no new GNOME was available for 11.0, even though some members of the GNOME team tried to package it for 11.0. [0] Whether that will hold true for 11.2 or not, I don't know.

We had to can that backport for several reasons. We will, however, make every attempt to build GNOME 2.26 for openSUSE 11.1. We have actually already enabled both openSUSE 11.1 and Factory and while we update to latest GNOME, we will be able to fix whatever breaks as we go.

Cheers, Magnus

2008/12/16 Stephan Kulow coolo@novell.com:

Am Montag, 15. Dezember 2008 16:08:41 schrieb Rob OpenSuSE:

...

2008/12/15 Michael Loeffler michl@novell.com:

...

Psychologically, I'd like to see 2 RC's series releases, to encourage more tester's who avoid 'Alpha' & 'Beta'.

Actually what I want to get away from with this release is Alpha, Beta and RC. Our Alphas are usually not less stable than our betas and our RCs are usually not 100% release material. So I want simple Milestones with goals associated to it. These goals wouldn't be much different from what we have now, but it would make it more clear IMO.

That sounds like an improvement to me. Giving some focus to the testing, makes it less daunting, and more likely to attract testers with better understanding of the particular area.

On Tuesday 16 December 2008 22:45:57 Stephan Kulow wrote:

Am Montag, 15. Dezember 2008 16:08:41 schrieb Rob OpenSuSE:

...

2008/12/15 Michael Loeffler michl@novell.com:

...

First we talked about July '09 release to come close to an 8 months release cycle. But KDE 4.3 is scheduled for release on June 30th and probably an OpenOffice.org release will be out end of June as well - both wouldn't make it into a July openSUSE 11.2. Therfor we're now thinking about a September release.

Let us know what you're thinking about this.

I like the thinking, but I have tended to move to every other release in past skipping 1 release, as twice yearly upgrades tended not to be time effective, especially when important upgrades were available for a previous release.

Psychologically, I'd like to see 2 RC's series releases, to encourage more tester's who avoid 'Alpha' & 'Beta'. This could be at expense of the last Beta's, giving time for wider testing of the kernel on real hardware, with a chance for more fixes for less common drivers, making it into the GM version, so the final release boots flawlessly on more boxes.

Actually what I want to get away from with this release is Alpha, Beta and RC. Our Alphas are usually not less stable than our betas and our RCs are usually not 100% release material. So I want simple Milestones with goals associated to it. These goals wouldn't be much different from what we have now, but it would make it more clear IMO.

I like the idea very much. But thinking about it, it might be hard to beat the drums early enough for upcoming release. But maybe "2 milestones to go" would work. Definitely something we should try.

Stano

On Mon, Dec 15, 2008 at 12:49 PM, Andrew Joakimsen joakimsen@gmail.com wrote:

I think waiting for KDE 4.3 is a great idea. Right now on the 11.1 release there are many features in KDE missing that used to be in KDE 3.5 (unless they somehow found their way back in between RC1 and GM, lol). I feel the main focus should be to identify those features and make an effort to add them.

A brief reminder - while openSUSE and Novell contribute a great deal to KDE, we don't guide the project or all KDE development. So, identifying "missing features" and seeing to it that they're available in 4.3 is (at least in my opinion) a bit beyond the scope of our KDE developers.

They've done an outstanding job of back-porting features from 4.2 to 4.1 for openSUSE 11.1 and making it exceedingly nice, but putting the burden of KDE 3.5 feature parity on our crack squad of KDE folks is a bit much to ask.

Best,

Zonker

Le lundi 15 décembre 2008, à 22:50 +0100, Stephan Binner a écrit :

On Monday 15 December 2008 14:43:03 Michael Loeffler wrote:

...

2009-05-28 openSUSE 11.2 Alpha 4 2009-06-25 openSUSE 11.2 Beta 1

One thing I would like to see in general is feature and version freeze not coinciding with last submission day for Beta 1 - so for above dates not on 19th June but for example on 5th (Friday) or 8th (Monday).

+1 (although I'd put the deadline on 12th in this case)

Vincent

On Tuesday, 16. December 2008 03:53:27 Kevin Dupuy wrote:

The only concern I have is whether we'll make the fall GNOME release, but I suppose we can't please everyone, and we've narrowly missed some KDE releases in the past, so it'sprobably our turn ;-).

I don't want to start a flame war but to me the current changes in GNOME2 in each release look rather non-critical to the ordinary user (read, they are more nice to have features).

In opposite KDE currently does a bigger jump with each KDE4 release and (re-) adds undebatable important features (read, not being in sync with the release either causes backport efforts or noticeably hurts users not having latest).

Looking forward to not miss a new KDE4 release by one or two months the third time in a row :-)...

Bye, Steve

Am Dienstag, 16. Dezember 2008 04:06:10 schrieb Carlos E. R.:

On Monday, 2008-12-15 at 14:43 +0100, Michael Loeffler wrote:

...

But it has its downside as well. Finalization of the release would happen during the summer holiday season. To address this we we added one Beta to stretch the development time a bit.

Some people might have difficulties contributing during the summer holidays. Me, for instance... I won't have my ADSL network, maybe not even the computer, during August. So certainly I will not do any testing, and very probably no translations.

Yeah, that's why we need to move slowly over august. I.e. freezing development mid/end of july and only do RC releases over august. But RC phase means we only fix critical bugs and we will get a lot of complaints about bugs not being fixed. But every bug fixed may cause regressions.

Greetings, Stephan

2008/12/19 Vincent Untz vuntz@opensuse.org:

...

openSUSE 11.1 is almost out of the door and we (coolo, aj, zonker and myself) had some discussion about the release date for openSUSE 11.2.

So I read the whole thread -- that's quite interesting. I'm replying mainly from a desktop point of view, which I guess isn't that surprising

First, a few facts:

That was a very clear and interesting summary.

Or we keep the proposed schedule. And use Magnus' idea of creating an add-on, but in a different way: release openSUSE 11.2 with GNOME 2.26 and create an (semi-?)official add-on for 2.28 that we release in early October. Looking at this add-on could be interesting to see if it's possible to ship an updated and working GNOME after less than 4 weeks after the GNOME release. I don't know how the GNOME team (and more generally, the users) would like the idea, but I find the challenge of having the distro accept a big official update as an add-on quite interesting.

From a current KDE 3.5 user perspective, shipping the "core" with

KDE-4.3 with a stable GNOME sounds good.

The distro can get more publicity, by pre-announcing the GNOME 2.28 addition on the stable base of 11.2 + updates, and then issueing new Live CD's as a 11.2.1 or 11.2 + GNOME 2.28 Addon.

In past, SuSE made significant updates available to the "attentive" user base. But it never seemed to be "loud and proud" enough to get mindshare and break the meme, that the release packages were somehow fixed in stone and unchanging, such as is case in Debian "stable" for instance. So the ppl who read SuSE usenet or forums, or mail lists would know they could install software upgrades, but not the average Linux user reading magazines or news sites.

I like the idea, of big softare packages and environments, shipping when they're ready and meeting good quality standards, rather than having to ship as is, because of an important event. That leads to having to replace almost every package soon after with update.

On Fri, 2008-12-19 at 11:48 -0500, Joe 'Zonker' Brockmeier wrote:

I like the way you're thinking... ;-)

Let me just say, first, that let's *never* plan a release a week before Christmas again, Mmmkay?

(Though we haven't failed to get the word out: http://zonker.opensuse.org/2008/12/19/opensuse-111-coverage/)

For future releases, if we can just rule out anything between the week before Thanksgiving and, say, January 10th or so, that'd be spiffy.

Absolutely. From a logistical perspective, this release has made the boxed edition shipments to North America slip until after the beginning of 2009. Already I've seen some disappointed users who purchased boxed editions as Christmas gifts become angry at the fact they won't be arriving on time. Although that's another problem (in another thread), if we're still going to have this issue with the boxed editions taking a few weeks to arrive in North America, that needs to be counted into the decision (read: no right-before-major-gift-giving-holiday releases!)

My thoughts, from just the marketing perspective:

July and August - we have major events (assuming the economic climate doesn't torpedo them...) during those months, and the opportunities for coverage are really good. We did a push for the openSUSE Build Service 1.0 in July, and did pretty well, all things considered.

Yes, a lot of people are away on vacation, but by the same token, they're good months because (usually) little else is going on.

Good point, although couldn't we get some coverage also if we show off a beta of the product at these shows? Do some demos of cool new stuff that we're certain to have in 11.2, even if it's not the final version?

On Fri, 2008-12-19 at 13:21 +0100, Vincent Untz wrote:

Sooo. First, a question: would a release at the end of July or in August be possible? I think doing this would clearly mitigate the "we don't have the latest GNOME" issue. I'd also like to hear what Zonker thinks of promoting a new release during days that are usually really quiet from a news perspective (mainly because people are away).

That would be my preferred option, to be honest.

I agree that releasing during quiet periods is definitely a nice thing if we can do it, but do we really want to do another quick 6-month cycle?

Then, we have the option with a release at the end of October or in November/December. This means releasing at the same time as Ubuntu/Mandriva/Fedora unless we aim at December. Not sure it's good (because it will likely mean less media coverage). And the cycle is a bit long. (not even talking about the SUSE conference that should occur in September)

As long as we release either before or after mid-October we should miss the Ubuntu news frenzy. Fedora is more of a wild card, but late November is probably a good bet for them. So pretty much anytime up until mid-October, then from late October until the U.S. Thanksgiving week (per what Zonker's said).

Or we keep the proposed schedule. And use Magnus' idea of creating an add-on, but in a different way: release openSUSE 11.2 with GNOME 2.26 and create an (semi-?)official add-on for 2.28 that we release in early October. Looking at this add-on could be interesting to see if it's possible to ship an updated and working GNOME after less than 4 weeks after the GNOME release. I don't know how the GNOME team (and more generally, the users) would like the idea, but I find the challenge of having the distro accept a big official update as an add-on quite interesting.

By "add-on", what do you mean? An extra CD to download, or an online update (like a Service Pack, basically)? I'm not so hot on the idea, especially considering it'd be only a month or so after 11.2's official release anyway.

Le vendredi 19 décembre 2008, à 22:03 -0600, Kevin Dupuy a écrit :

On Fri, 2008-12-19 at 13:21 +0100, Vincent Untz wrote:

...

Sooo. First, a question: would a release at the end of July or in August be possible? I think doing this would clearly mitigate the "we don't have the latest GNOME" issue. I'd also like to hear what Zonker thinks of promoting a new release during days that are usually really quiet from a news perspective (mainly because people are away).

That would be my preferred option, to be honest.

I agree that releasing during quiet periods is definitely a nice thing if we can do it, but do we really want to do another quick 6-month cycle?

July-August would be 7-8 months, not 6 months. I would say it's okay, but there are indeed quite a number of people willing something around 9-10 months.

...

Then, we have the option with a release at the end of October or in November/December. This means releasing at the same time as Ubuntu/Mandriva/Fedora unless we aim at December. Not sure it's good (because it will likely mean less media coverage). And the cycle is a bit long. (not even talking about the SUSE conference that should occur in September)

As long as we release either before or after mid-October we should miss the Ubuntu news frenzy. Fedora is more of a wild card, but late November is probably a good bet for them. So pretty much anytime up until mid-October, then from late October until the U.S. Thanksgiving week (per what Zonker's said).

Anytime up until mid-October is not an option if we need four weeks after GNOME 2.28.0. So it'd leave us with late October to US Thanksgiving.

...

Or we keep the proposed schedule. And use Magnus' idea of creating an add-on, but in a different way: release openSUSE 11.2 with GNOME 2.26 and create an (semi-?)official add-on for 2.28 that we release in early October. Looking at this add-on could be interesting to see if it's possible to ship an updated and working GNOME after less than 4 weeks after the GNOME release. I don't know how the GNOME team (and more generally, the users) would like the idea, but I find the challenge of having the distro accept a big official update as an add-on quite interesting.

By "add-on", what do you mean? An extra CD to download, or an online update (like a Service Pack, basically)?

This is undefined as of now :-) It's up to us to define this if we want to go this way. Intuitively, if we go this route, I'd like to see:

+ some re-spinned DVD/Live CD for GNOME (version 11.2.1, eg) + some online repository that people can add + some CD containing packages from this repository and that people could put in their cd-rom drive, which would automatically propose the update

(one issue I forgot to mention in my previous mail about this solution is: what would we maintain? One or two versions of GNOME?)

I'm not so hot on the idea, especially considering it'd be only a month or so after 11.2's official release anyway.

Can you develop this point? I only see this as a problem to handle from a marketing point of view (and that can turn into a nice opportunity).

(note that I still prefer the july/august option ;-))

Vincent

Le samedi 20 décembre 2008, à 14:48 -0600, Dean Hilkewich a écrit :

How about just getting the Yast Product Creator to the point where one can easily "re-spin" installation medium with the updated packages?

I think we can already do this with the build service. At least, home:coolo:LiveCD makes me believe this.

Vincent

The quick forum poll has 42 replies 22nd December at 1600h GMT :

http://forums.opensuse.org/surveys-polls/402364-release-style-preferences-wt...

View Poll Results: What Release Model Would You Like Best?

Current One - 3 Releases in 2 Years, Some Upgrades via Build Service 11 Rolling Release - "stable", "current" and "factory" well tested upgrade for stable 13 6 Monthly Release following KDE & GNOME 2 Annual Release with more time for Development & Testing 13 Other (please explain your preference) 3

The votes for annual took off, after posting in the "install" section of forum. A lot of ppl seem to be upgrading from 11.0, without a clear reason why, just to have the latest. Then running into forseeable troubles and known issues.

There's some comments about the "stress" factor of upgrading the release. Rolling release appeals, precisiely because many small steps are less worrying than a huge automatic one, that updates the whole system.

So the proposed schedule would appear to be popular with most of the user base, who've responded.

Short question -- sorry it was already brought up and I missed it. Has anyone considered GNOME 2.26 + backports for 11.2? In typical GNOME style 2.28 won't probably have any earth-shaking new features, but maybe there will be some nice little feature here and there, like 2.16's Evolution has Exchange 2007 connectivity.

On Sunday 21 December 2008, Dean Hilkewich wrote:

...

I think we can already do this with the build service. At least, home:coolo:LiveCD makes me believe this.

The build service is a horrible option for Joe User to attempt to create their own "updated" installation medium.

It is actually quite easy to do. The reason it appears to be complex is because it is not documented and nobody did it publically before (well, except if you watch the livecd project really closely).

I think it is really easy with the buildservice to create "spinoffs" or "openSUSE flavors", so there could be a "latest GNOME" flavor of openSUSE 11.2 being created automatically. In a future life when I have more time I would also like to create a "latest KDE" flavor based on the latest released openSUSE base distro.

Greetings, Dirk