[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When Debian 4.1 will arrive... will anyone care?



On Sat, Apr 14, 2007 at 07:08:08PM +0200, Raphael Hertzog wrote:
> On Sat, 14 Apr 2007, Wouter Verhelst wrote:
> > > 	Some users, I guess some developpers and contributors, and at
> > > least myself, find it very demotivating to think that a new release
> > > means that nothing will happen anymore in Debian stable in the next 24
> > > months.
> > 
> > If that is really the case, then you should not use Debian stable.
> > Debian stable is there to be rock solid; expecting anything else is
> > having unfounded expectations.
> 
> What's wrong in wanting something rock solid released more often than
> every 2 years ?
> 
> I know corps want a stable release that last more than one year, but that
> shouldn't forbid us to support one release for 3 years and have good
> intermediary releases with less support.

While I hear a lot of voices complaining about "the software is outdated
the moment that a stable release is announced" I need to run the stable
distribution on a few servers at work. And I'm very grateful that I
don't have to evaluate the new software and migrate my configuration
every half year. Being rock-solid is important for me even if it's
boring to some desktop users with featuritis (I am no exception).

Regarding intermediary releases: let's try to keep the "testing"
distribution in the best shape possible. If I want to have the newest
versions with a very low chance of ruining my system I'd say that
"testing" is even a good choice for production systems. You ask me if
I'm mad? :) Well, I have looked over the shoulder of fellow
administrators who run very important production systems and they
sometimes have an all-from-scratch approach. The compile everything
manually into weird paths like
/usr/local/install/herbert/usr/share/apache/etc/apache2.conf... - no
they don't use Debian nor would they care. I wouldn't touch their
systems with a 10-meter pole. The point is that they run the newest
software and don't even care about getting security support. If there is
a critical bug they need to recompile the software... so guess how
quickly they react on security bugs. They might happily use the
"testing" distribution even if security bugs would just be fixed by a
subsequent upload two weeks later. So if "testing" is in acceptable
shape it could well be the mainstream distribution of Debian. (No, on my
most important servers I wouldn't do that.)

Or take Ubuntu. They are delivering what is mainly testing/unstable with
some manual corrections and tell their users that it's their "stable"
release. Just stamping "stable" on it doesn't make it stable. A lot of
coworkers are happily using Ubuntu flavors but deal with bugs that I
wouldn't expect in a Debian "stable" release. (One month ago I had to
backport "rdesktop" because the current version in Ubuntu has some
graphical redraw glitches which were documented in the BTS already. It
was "sold" as "stable" though.) Don't get me wrong - I love Ubuntu
although I don't use it on my systems. It's a matter of facts that you
can't release a stable Debian-grade release every 6 months. I think that
Debian users might go the same route though: "give me newer software
that is packaged well - I'll accept occasional problems". At least
that's how I believe most Windoze users live: they always want the
newest software and don't mind reinstalling their whole system if it
breaks in the process. At least these are the daily stories I hear when
waiting in the queue of my favorite PC shop. :)

There are three issues that I thought about for a while when following the
frequently upcoming discussion about this "Debian is too stable" topic:

(1) Packages depend always on the newest other package versions

Most of the time the (automatically calculated) dependencies of packages
that go into unstable are on other packages from unstable. Users on the
stable distribution can't use it because e.g. libraries on their system
aren't new enough to satisfy the dependencies. The obvious solution is
backports. But most of the time the dependency doesn't have to be that
strict. Do you really need a libc6 of version 2.3.6 or is >=2.1 good
enough? Most packages aren't available as backports so the user would
obviously dist-upgrade to "testing" or "unstable" thus ruining the
rock-stableness of the system. Some maintainers deliberately maintain
the dependencies manually so their packages can be used on a stable
distribution. Can't every maintainer do that? (Serious question. I'm not
sure if/how that's technically feasible.)

(2) Why is "testing" the preparation for the next stable release?

I know the deal... "testing" is frozen and becomes the new stable
release. During the pre-release period package maintainers are asked not
to upload new versions or use "experimental" for it. A few weeks ago my
system consisted of so many packages from "experimental" that I couldn't
even count them. If - as I propose - the mainstream user uses "testing"
then it should always be fueled with new packages from "unstable" as
usual - even during the weeks before a release. Can't the release
managers just copy the whole "testing" distribution into a new "etch"
branch and work on "etch" without further touching "testing"? If they
decide they want a newer package in due to a package maintainer's
request they can well copy it from "testing". But some coworkers use
"testing" all the time and during the time before a release encounter
more brokenness than during the normal times without a release in sight.
Another advantage: more users are testing what will go into the next
"stable" release. This could mean a higher quality with less bugs if
only they would start to use the BTS... they probably won't. And at
least the shouting of "What? You use 'testing' and dare ask on
debian-user* about broken packages?" would vanish.

(3) The names of the distributions are misleading

"stable" is stable. Perfect.

"testing" isn't what desktop users would want to use - at least not
by that name. They don't want to test things. They want current packages
that aren't too broken or have too obvious bugs. Why not call it
"current"?

"unstable" isn't unstable at all. The set of packages is in permanent
flux, yes. But it makes a good desktop system if you know how to scratch
the itches. Why not call it something like "developer" or "incoming"?
It's meant for package maintainers mainly IMHO.

Yes, it's about appearances. Marketing is important although I don't
really like it. Most of us know why we use Debian and contribute to it.
But compare www.debian.org to any other web site of an operating system
- it's plain ugly. (Yes, I know... contribute patches.) If I didn't know
Debian I'd see that "stable" might frustrate me with old packages and
the web site is ugly. Why are we proposing screenshots.debian.net?
Because what draw quick conclusions from what we see. I can already hear
the voices saying "if a user judges us by the looks of our web site they
shouldn't use Debian". :)


In my imagination "testing" would be called "current" and used by the
majority of home desktop users. It wouldn't be frozen during release
times. "stable" would be installed on servers that you need to earn your
living with or on corporate desktops. And "unstable" would be called
"incoming" and just be used by the 'inner circle' of package
maintainers. Is that too far fetched?

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--                1,48         All



Reply to: