Re: Implementation of Developer's DB
On 10 Jan 1998, James Troup wrote:
[snip]
> > Just let me note, that all packages that are currently maintained by
> > a group of developers, have a much longer list of outstanding bug
> > reports than most one-maintainer packages, for example dpkg,
> > boot-floppies, doc-debian containing the FAQ (not much bugs, but the
> > FAQ is actually orphaned).
>
> You're ignoring several things. Both dpkg and boot-floppies are very
> complex packages, and like any other complex package (X, emacs, perl),
> they have lots of bugs. I agree dpkg isn't well maintained at the
> moment, but I think that has very little to do with it being group
> maintained and much more to do with the fact that a) very few people
> are qualified to maintain and fix dpkg, and b) those who are, are,
> unfortunately, very busy.
I'm still not convinced by your arguments. Of course, these packages are
complicated (and another problem might be that we are the upstream
developers of "dpkg" so we'll have to do the coding, too). However, the
whole organization of the Debian project is based on the fact that we have
about 150 developers, who all contribute and maintain different packages.
By now, we don't have much "organization" between them.
As long a single developer takes care of something, everything is fine.
However, as soon as you need several developers to work on the same topic
things get much more complicated. (Just look how long it takes for a
project like the `keyboard configuration project' to get some first
results--that project is not focussed on a single package, but tries to
"coordinate" between packages.)
Note, that I'm not saying that the current situation is bad. Obviously,
you'll never know how much time each volunteer can contribute the next
days/weeks. We've solved this by allowing `non-maintainer' releases.
The approach `one maintainer per package' is just a representation of our
development model and the past releases have proven that this model isn't
totally wrong.
> Boot-floppies on the other hand is being actively worked on, although
> it might not appear so to the outside world, there is a lot of work
> being done. Don't believe me? After 2.0 is released, check the
> differences between bo's bootfloppies package and hamm's. Also don't
> fall into the trap of judging a package or it's maintainers by the
> number of bugs. That's just wrong. In both the case of dpkg and
> boot-floppies there are lots of bugs which are non-trivial to fix
> (e.g. "dselect sucks").
I'm not judging packages or maintainers because of bug reports. However,
comparing the length of the bug list with the frequency and the date of
the last upload gives some indication whether a package is `actively
maintained' or not.
With that, I consider dpkg to be `not actively maintained'. (Note, that
this is not meant as an insult against Klee or Ian, who both did and
currently do a great job for the project. It's quite obvious to me that
the project leader does not have time to maintain dpkg. I think it would
be fair to ask them about whether they think they'll have time again for
dpkg in the next months. If not, we should find someone else taking over
the package. dpkg is way to important to leave it unmaintained.)
> > This does not mean that we don't allow several maintainers to work
> > on the same package. However, one of them should be listed as
> > maintainer and feel "responsible" for the package and possible bugs.
>
> If you got several people working on a package, why should one person
> be responsible for the bugs of other people? That's silly.
Not responsible for the bugs, but responsible for having the bug reports
handled. (This could be, to fix the bug himself or to find someone else
fixing the bug, etc.)
BTW, here, responsibility does not mean we'll punish someone for any bugs.
Hey, we are a volunteer organization and we all want to have fun! However,
as we are trying to build a high quality distribution and the different
developers invest a _lot_ of their spare time, we'll have to accept that
this requires some "responsibility" how we treat other developers, etc. of
us all.
Putting ones name in the "Maintainer:" field is like saying `Hi folks, I'm
taking care of this package for now. If there are any problems with this
package, feel free to contact me and I'll see what I can do.'
For a long time, I've silently accepted that some packages list several
maintainers and thus don't comply with current policy. I'll continue to do
so in the future. These packages can be used to do the experiment if
packages with several maintainers are better maintained than
single-maintainer ones. (However, doing experiments on dpkg might be a bad
idea :) But unless someone proves by example that this is true, we should
not change policy WRT this question.
Thanks,
Chris
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com
schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
CS Software goes online! Visit our new home page at
http://www.schwarz-online.com
Reply to: