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

Making better use of multiple maintainers



During the base freeze preparations in the last few weeks, a problem
Debian has always had became apparent again.  Since Debian is a
distributed, volunteer run project it is hard to tell whether a maintainer
is doing Debian work at the moment.  In the freeze, it is often crucial to
get a bug fixed within a very short period of time.  If the maintainer
doesn't respond to e-mail immediately, you can either wait or make an NMU.
The former is problematic since it might delay the freeze and the latter
might break the package, which in turn would cause a delay (Of course NMUs
don't always break the package but the likelihood of breaking a package is
higher if you don't know the package well).  A feature has recently been
implemented in dpkg/katie which could solve this problem (along with a
couple of others) if deployed properly.

In Debian, a package usually has one maintainer.  When someone other than
the maintainer makes a source upload, katie recognizes the upload as an
NMU and tags the bugs as fixed instead of closing them.  Since some
packages have multiple maintainers, an Uploaders field (in debian/control)
has been introduced in dpkg 1.9.13 (see #101815) -- katie now also checks
this field in order to determine if the upload is an NMU.

What I'm basically proposing is that it would be nice if packages had a
backup maintainer or two listed in the Uploaders field.  The maintainer
could ask someone with whom he works together well and whom he trusts if
he wants to co-maintain the package.  The maintainer would still act as
the package's official maintainer, but the other one can act as a backup
when the main maintainer is busy or on vacation.

I think we should try to implement that scheme at least for packages in
base and standard... but why not go ahead and try to do it for all
packages?

Now, while this proposal may sound like a simple idea, it has wide ranging
implications:

  - Bugs could get fixed sooner since more people are working on the
    package.  This would help us meeting our release goals.

  - There would be less breakage due to NMUs because there is a backup who
    knows the package well.  This would also give maintainers more control
    over who's likely to work on their packages if an emergency arises.

  - When the maintainer loses interest in a package, he doesn't
    necessarily have to orphan it and wait for someone to pick it up.
    Instead, he can immediately give the package to the backup maintainer.
    Orphaned packages often don't get the attention they would deserve and
    this might fix that.

  - Packages in the base system have more bugs than other packages.  Now
    you may say that this is logical since more people use base packages
    than some other packages.  But why don't we take this to the logical
    conclusion and have more maintainers for common packages?

  - The concept of one-package-one-maintainer doesn't necessarily have
    to be kept.  As mentioned previously, I think it makes sense that
    common packages have more maintainers.  This would mean that packages
    would get more attention and more bugs fixed.  The BTS allows more
    than one person to get bug reports for a specific package (through an
    overwrite file) and in the future it will be possible to subscribe to
    individual bugs.  The backup maintainer could follow the bug reports
    and assist the maintainer.

I don't want to force this upon people.  You are the maintainer of your
packages and it's your decision whether you want to add backup
maintainers.  However, I feel that having multiple maintainers for
packages could lead to a big increase in Debian's quality.  At the moment,
Debian is growing quite dramatically in size but I'd love to see more
manpower devoted to existing packages instead of (or in addition to) new
packages.



Reply to: