2009/1/7 Gerald Pfeifer <gp(a)novell.com>om>:
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org