Mailinglist Archive: opensuse-project (328 mails)

< Previous Next >
Re: [opensuse-project] openSUSE 11.2 schedule
  • From: "Rob OpenSuSE" <rob.opensuse.linux@xxxxxxxxxxxxxx>
  • Date: Tue, 16 Dec 2008 13:55:07 +0000
  • Message-id: <ce9d8ed60812160555r60513099sb24ccec75bc8f0@xxxxxxxxxxxxxx>
2008/12/16 JP Rosevear <jpr@xxxxxxxxxx>:
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >