Some thoughts about problems within Debian
Hi,
I had several discussions with people on Debian lists that became very
emotional. They thought that they were right in a discussion and I thought
that I was right and nothing but anger resulted from these discussions.
Several times the "opponents" in these discussions are people that are
longer in Debian than I am and that do a damn good work in the area(s)
they are working for Debian and I do acknowledge this even when they call
me a troll. I try to summarize the most important points below - not
because I consider it important that I'm right but because these are IMHO
very serious problems in Debian. Please read it, try to understand it and
make your own opinion of whether I'm right or wrong.
When I see problems somewhere I tell them even in the case when I don't
know a solution - IMHO pointing to a problem is something valuable to help
improving something. I do often try to see the point of view of the people
we are doing our work for - our users.
Everything I mention below isn't meant to offend against anyone
personally.
Debian becomes bigger and bigger. We do currently have over 900 people
maintaining over 8000 binary packages [1] and there are currently over 350
RC bugs in packages that are in testing [2] plus many more in packages
that were either removed from testing or never made it into testing.
Debian is well-known for high-quality releases and I consider it important
to preserve the high quality though we have so many different people
maintaining so many packages.
One important thing are more frequent releases. We don't have to release
as often as other distributions but IMHO it's needed to have a new stable
release at about once a year. Currently the software in our stable release
is two years old and I see several distributors and magazines already ship
woody CDs instead of potato CDs although we are still several months away
from releasing woody - and if people encounter problems with the packages
they find there this does in the long term harm the good reputation of the
quality of our packages. There are many reasons why you need packages you
can't find in potato. Sometimes it's only that you want to use Gimp 1.2
but often there are important reasons like e.g. support for kernel 2.4 or
Euro support in some applications. Using testing isn't an alternative on
many production systems because testing reduces the probality of bugs but
it could still happen that e.g. your X does no longer start after your
latest upgrade to testing.
In Debian a package normally belongs to exactly one maintainer. The
possiblity to overrule the technical decision a maintainer makes and to
force a maintainer to e.g. implement a proposed solution from a bug report
is mostly theoretical. This maintainer-centric approach gives very much
power to a maintainer and I think that there also an obligation for a
maintainer to take care of his packages.
Most of us who work for Debian do this in our spare time. But I do
personally disagree with the "you can't force a volunteer to do anything"
argument I heard in several discussions. These were discussions about
things where some work of the maintainer who is responsible for his
package would save work for other people who do volunteer work for Debian
or to improve the general quality of Debian for our users.
Examples are e.g.:
- Old RC bugs that are easy to fix.
These bugs need someone to do a NMU and I'm often negative surprised in
bug squashing parties how many RC bugs that are open for more than one
month are easy to fix because there's e.g. only a missing build
dependency. This makes it harder to get Debian in a state to release and
it takes time at bug squashing parties to fix these bugs - time you
could otherwise use to try to fix other bugs. Additionally one buggy
package might prevent many other packages from entering testing which is
very frustrating for the maintainers of the packages that don't make it
into testing because of this.
- Make debconf mandatory for all packages that interact with the user
while installing/removing a package in woody+1.
One positive effect would be for the user that he doesn't has to answer
questions several times during the installation of the packages - he can
instead go to drink a cup of tea after he answered the debconf questions
that come en bloc. Another positive effect is that this makes life
easier for everyone working on automatic installations of Debian.
Don't misunderstand me: I know that a package maintainer also has "real
life" things to do that might have higher priorities for him personally.
On the other hand he is responsible for the packages he maintains and IMHO
this implies that we can expect from a maintainer that he tries to fix RC
bugs in his packages at least once a month and to try to fix the other
bugs in his packages from time to time [3]. If it's generally agreed that
all packages should comply with with something that is generally
considered important I think it's OK to force all the maintainers to do
such a change within a reasonable long amount of time (e.g. half a year or
a year).
There are already several places where we force a maintainer directly or
indirectly to do something. The FHS transition was an example and another
one is the setting of the Section and the Priority of our packages in the
override file - if the ftp admins decide that a package should e.g. be
only Priority "extra" the maintainer can do nothing do against it.
There's another implicite way to force a maintainer to do something: Buggy
packages get removed from testing or they never enter testing. At the
first sight this is a punishment for the maintainer who doesn't fix the
bugs in his package (besides the fact that with testing this punishment
might also affect packages whose maintainers do maintain their packages
perfectly). But if you look closer you'll see that it will harm Debian as
a whole if popular packages like e.g. evolution that are currently not in
woody won't make it into the stable release (many users will say: "What?
Debian has so many thousand packages but this popular package that is in
every other distribution isn't in the recently released Debian 3.0?").
Thanks for reading my mail
Adrian
[1] http://www.debian.gr.jp/~kitame/maint.rhtml
[2] http://master.debian.org/~wakkerma/bugs/
[3] "tries to fix" means that he looks into the bug. I do expect a
maintainer to be able to fix a "missing build dependency on xyz" bug
or to forward the bug to upstream. OTOH it's clear that there are
cases where the maintainer can't do much about a bug (e.g. there's an
inactive/dead upstream and he can't fix a bug in the source himself).
Reply to: