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. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org