On Tuesday 03 Feb 2009, Birger Kollstrand wrote:

Would it be possible to have multiple levels of SW with different kinds of release regimes?

The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.

Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching.

This makes sense, but from my perspective there is one change in viewpoint. I'dsuggest the release roadmaps are based around what can be done with the release rather than what software is in it. So it could be the target for a release to support (amongst other things) synchronisation with a range of PDAs or some such. A desktop is just a platform on which these useful things are built, so is necessary to support this, not an end in itself. It's only software developers who care about what packages or versions are included. Everybody else whats to do something with the software. That said, each release should preserve what was working before. Often new releases break stuff the developer wasn't interested in (and the people who are happy with the old functionality don't test the new as they don't need it). David -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tuesday 03 February 2009 23:43:41 Birger Kollstrand wrote:

Hi all,

There is discussions ongoing for the schedule of 11.2 and there is always the connection to this and that big project.

Is it not possible to rearrange the distro release so that we are not depending upon these release dates?

Would it be possible to have multiple levels of SW with different kinds of release regimes?

The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.

Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching.

Then again applications can be released based upon build service projects and feedback from users, maybe a voting system where there is a need for a qualified number of votes stating this app is ready for update.

With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.

There are maybe technical hurdles, bandwidth considerations etc. ?

I have the following questions: * How and when to release media? * Even if you update the base system, you might need to update the desktops so that they work together. * How would a sample release schedule work? (without dates)

(Taking on my flame protective gear...)

Hope that's not needed ;). We do need some out-of-the-box thinking... Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

...

With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.

Is there an example where such a release mechanism is successfully used?

Gentoo? Kinda sorta. If a Gentoo box is updated with an emerge world (or something less dramatic) it is updated to the latest rolling releases... C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/2/4 Cornelius Schumacher :

On Tuesday 03 February 2009, Birger Kollstrand wrote:

...

With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.

Is there an example where such a release mechanism is successfully used?

Let's just move to the well proven Debian model then, but without the pedantry. Then you have, Ubuntu & Fedora using 6 monthly time based releases and openSUSE being different (not just slower). openSUSE installer + ISO's can then be released, when the stable version would benefit from new packages (ie the testing version is solid). As it stands, all the incentives are towards "free loading", letting other ppl doing the testing, and it's hard work to get closer to the development versions. Actually receiving & seeing fixes as they're done, rather than waiting till install of new released version favours participation more. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/2/4 Eric Springer :

On Wed, Feb 4, 2009 at 8:24 PM, Rob OpenSuSE wrote:

...

As it stands, all the incentives are towards "free loading", letting other ppl doing the testing, and it's hard work to get closer to the development versions. Actually receiving & seeing fixes as they're done, rather than waiting till install of new released version favours participation more.

Absolutely. However, we do need a better (read: great) way of catering for users who do not wish to be part of said feature/major upgrade cycle (on a package and a system level).

Well Debian stable, is a security and serious bug fix only version, really it's very similar in concept to running 10.3 or 11.0 now, rather than the new fangled 11.1. Those who want to avoid an unplanned upgrade would simply use "etch" in their sources list. What happens in a release is policy, not inevitably decided as a consequence of technical decisions. Possibly you could by default enable and automatic weekly update for critical fixes, and at "End of Life" warn user of unsupported status on the Login page, may be suggest switch to SLE like terms, if they want extended support, rather than upgrade. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Clayton escribió:

...

...

With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level. Is there an example where such a release mechanism is successfully used?

Gentoo? Kinda sorta.

He said successfully... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tue, 3 Feb 2009, Birger Kollstrand wrote:

The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.

As some of us tend to say, the kernel tends to be overrated. ;-) Yes, it provides the name to Linux or GNU/Linux, if you will, but from a desktop user perspective, for example, I should hardly notice if the kernel changes whereas an update to Firefox, OpenOffice or the desktop environment of choice is much more noticably and possibly distracting. You idea as such is interesting, though! I guess I'd just move what you call "basic level" a bit upwards and potentially give more leeway on the kernel side. (The toolchain and glibc might be other candidates for such a "basic level".) Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rob OpenSuSE escribió:

Let's just move to the well proven Debian model then,

It has been proven to be very useful to produce distributions in timely manner, aprox every 5 years and/or to provide new distributions with completely obsolete software to users. **grin** -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/2/7 Cristian Rodriguez :

Rob OpenSuSE escribió:

...

There just seems to be a general FUD about change. So for example "zypper dup" was there, but in 11.1 we don't commit solid behind it,

what you mean.. ?

The user base, don't think "zypper dup" is a supported upgrade method from 11.0 to 11.1, nor and there is a fate entry on supporting a "Debian like dist-upgradee".

...

and now for 11.2 in the fate entry, noone seems to be really sure what work needs to be done to make it "just work" for most end users.

What has to be done is pretty clear, why you get that impression ?

The fate entry on the subject.

...

There's a big danger, that openSUSE will look staler and staler,

I think we are far from stall...

After 2 intervening Ubuntu & Fedora releases 11.1 will look stale. The rough edges lead to unfavourable threads on forum and mixed reviews, and those show in Google search for a very long time. The KDE 4.1 with backports for 11.1 was nice, but that work seems to have very short shelf-life, given the timing of KDE 4.2. The thread proposes a way to make that less of an issue, and also planning to re-issue ISO's would hopefully help those who found 11.1 wouldn't boot on their machines. So far the improvement to Factory updates, seems to be the step that might lead to more testing earlier. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/2/8 Cristian Rodriguez :

Rob OpenSuSE escribió:

...

2009/2/7 Cristian Rodriguez :

...

The user base, don't think "zypper dup" is a supported upgrade method from 11.0 to 11.1, nor and there is a fate entry on supporting a "Debian like dist-upgradee".

It can be supported, but when using a limited set of known repositories, IMNSHO.

Sounds like a very good start.

...

The fate entry on the subject.

FATE cannot contain everything that has to be done or cleaned up before this to work, you can write a book of the size of "Don Quixote" on the subject, for the user is just zypper dup, internally for developers is a great deal of work, you have to deal with among other things

- API issues - ABI issues ( tricky as hell, hint hint) - Correct a huge set of packaging problems - track backward incompatible configuration changes, without destroying user's configuration - Debug and fix all the bugs introduced by this changes (and goto 1)

So far, no one has done it right...;-)

The Debian solution, which is generally praised, doesn't attempt to solve all of these things. They seem to have managed to make it work "well enough" rather than "bullet proof", and not guaranteed dist-upgrade (full-update) whilst running GUI for example. The "Debug & fix" point, is why it needs clear publicity and testing effort. People can plan test areas, copy their configurations across and try updating, if they know it is supported. If API & ABI issues are a problem, then statically linked tools that update files on disk from one consistent state to another, would seem to be a good solution. Disk formats could change to (like when RAID & LVM formats changed), but some documented non-live procedure, to upgrade deprecated features would likely solve it for most ppl.

...

After 2 intervening Ubuntu & Fedora releases 11.1 will look stale.

why it will look stale ? we are already making a new product , it takes time and considerable effort !

Simply because Fedora & Ubuntu will be re-freshed more often. For example 11.1 has KDE 4.1 + backports, which is not what real end users want, they actually want KDE 4.2 or 3.5.10 now, and 11.1 is still going to install a reviled KDE4 software version (I know that's unfair but it is the general perception). So the point of the thread was to discuss alternatives. It has been discussed (somewhat) before around Christmas time. Those making suggestions are looking for solutions : - perceived shortage of alpha & beta testers - perceived reliability & installation success - perceived drawback of tying openSUSE release to other projects - difficulty verifying bug fixes (they are 'done' but checking that, means upgrading to a release that may not be available till months later) Really the roughly 3 releases in 2 years, talked about is doing same thing as the other distro's just slower. As I have good memory of pain of installing 10.3, and time it took to stabilise on my machines (yes I was unlucky), I do not have faith that simply extending the time till next release, will really change anything. The move to make Factory updates more efficient, does seem like a step to improve the situation. The easier it is to get close to development, the greater number (in time) of useful tester and developer contributions.

so what ? you want a perfect OS ?.. Im sorry to bring you down to earth, there is no such thing and will most likely never be, people will always whine and complain anyway ..it is very easy to do so when you are not one doing the work...

Actually I agree, that does mean that it's wrong to look to improve the situation. As it stands, being an active openSUSE community member, testing the alpha's & beta's, is a fair amount of work, reported bugs don't necessarily get fixed, nor were work rounds published in release notes. When bugs are reported, sometimes it appears that the assigned engineers are under pressure to get them CLOSED or RESOLVED in some quick way, rather than really solved.

...

and also planning to re-issue ISO's would hopefully help those who found 11.1 wouldn't boot on their machines.

So you want people to waste the already limited resources available to respin a release just due to "being unable to boot on certain specific machines" ?? Im sorry but that does not qualify as a good reason for me.

11.1 failing to install on an 11.0 machine looks like a significant regression to me, and not a "waste" to resolve. If sorting that problem involves "waste of limited resources" then there's something very wrong in the release process. As it stands, it appears that the release mentality required for retail sales of box sets is entrenched. openSUSE users are not the types needing certification and QA approval processes. Those with good net connections, really want the best possible OS, more of the time, with different compromises on new feature / stability trade off. Those without decent net connections, need solid releases, not stuff that need lots of updates, or ones that don't boot. All the big community releases, not tied by policies of a commercial distributer, have gone for continuous update models, with periodic release of installation media. There's a reason for that, and is not because they didn't listen to end-user requirements, or were not dog fooding. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/2/9 Birger Kollstrand :

2009/2/7 Gerald Pfeifer :

...

On Tue, 3 Feb 2009, Birger Kollstrand wrote:

...

You idea as such is interesting, though! I guess I'd just move what you call "basic level" a bit upwards and potentially give more leeway on the kernel side. (The toolchain and glibc might be other candidates for such a "basic level".)

Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage.

Unless a different release model significantly increases those costs, is that question really relevant? For 11.2, we know that we will need kernel, glibc, gcc, binutils, bash, fileutils etc. Making the distribution, involves internal program developments, like YaST & zypper features, and intergrating the work of other projects. A benefit would also be if we can find things like kernel regressions now, in 2.6.29 before the kernel developer's have layered other changes dependant on alteration which caused the regression. Finding flaws sooner, and getting fixes integrated upstream, saves costs as it is easier to maintain than 'private' patches.

Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications.

Could it be an idea that in 11.2 , in paralell with the standard release, there is a "rolling" repository an that repository contains backports of KDE, Gnome and applications. The applications should then first be available in the build service and tested there, then discussed and eventually accepted on the factory list for inclusion in the "rolling" repository?

You mean, say that all 11.2 application improvements should be runnable on the 11.1 core, to try to increase the testing pool? Any package using a new feaure, involving higher version kernel, library, Xorg etc etc would have to fail gracefully with lower version, if not then that feature would have to wait till 11.3 or 12.0 release. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Mon, 9 Feb 2009, Birger Kollstrand wrote:

Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage.

Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications.

I was not thinking of cost, but the implications of updating. From that perspective, reving the kernel should be easier to do than the toolchain (including glibc). Nearly the entire distribution depends on the latter relatively directly. Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org