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

yup, we are dead ... NOT



Hello,

in light of the recent discussion, let's clean up some wrong assumptions:
(maybe this is a rant, I don't think so, because I have no anger writing it.
But then, I am under pharmaceutics :)

* Debian will die if we don't change.

Debian can't die. As a grop of volunteers, we will always reorganize
ourselves to meet urgent problems. This is a fear we don't need to have
(although we must not be ignorant of our problems, I admit).

* Debian stable is outdated.

May I laugh? Ever compared Debian stable with a most recent version of,
let's say SuSE? Don't make the mistake and compare only Kernel version,
Gnome, Gimp and gcc. Compare the full set. Make a list. Post the result, I
would like to see it.

It is obvious that commercial distributions pay a lot attention to have
always the latest Gnome, Linux kernel etc. This is not needed for Debian,
indeed, going this way would be problematic. We always ship stable,
preferable bug free software. Seeing distributions shipped with 2.2.x
kernels, x being smaller than 12, makes me nervous, because we all know how
unstable they are. Let's not join the marketing hype. Instead, we provide
instant update of _all_ packages via our "unstable" distribution which
hardly deservers its name.

I claim, that Debian stable is reasonable up to date and very stable indeed.
Everyone else updates parts of his system to unstable or tracks it
fully.

* Accepting new maintainers makes Debian more buggy.

What a deal! We just don't include the package into the release. IMHO, we
should be a bit more easy at hand with removing packages from the freeze
stage. This will encourage maintainers to do something about the bugs.

We always said that people who want to work on unstable only are not
hindered by the release cycle. Not all 500 people can/want to work on the
release. Let's not do this mistake. Not accepting new maintainers does not
make Debian any more stable, too. And, people will only learn if the y can
commit their sorta buggy package and get bug reports.

The real solution is to keep track of packages which are de-facto-orphaned,
and remove them from the distribution. The maintainer is always encouraged
to reupload them if he has fixed it.

* The /usr/share/doc issue dangers potato release.

Ridiculous. Neither proposal I read (that was actively discussed, anyway)
included changing all packages before releasing potato. Sadly, it is easier
to rant away than to check the facts (and there were quite a lot of
messages, and the ifnal result was posted on debian-ctte and debian-policy.
We should post it to debian-devel-announce, though, I am not sure if this
has happened. But this is not a problem, because it is not an urgent problem
and has hardly anything to do with potato).

===

In other words, if you get bigger and bigger, you have to learn how to
shrink, too. (If you need to remember a lot, you need to actively forget
other stuff). This will work quite well, I am sure, once it is exercised.
But there is no infrastructure for that, currently.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org  Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de                        PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/


Reply to: