first proposal for a new maintainer policy
When thinking about section 2.3.2 (`Every package must have exactly one
maintainer at a time.') again, I noticed that we haven't defined the term
`maintainer' in policy yet. Since the idea of `maintainership' is central
to Debian's open development model, I think it's necessary to define this
term in detail.
I am willing to change policy to allow packages to be maintained by
several developers at a time, provided that the duties and rights of the
involved developers are well defined, and one of the maintainers is
declared as `master maintainer,' who has the final word in case of
conflict situations.
Here is a first draft of such a `maintainer policy.' It would be nice if
people could give me feedback about it.
(The section `The Maintainer control field' could replace section 2.3.2 of
the policy manual, and the rest could be incorporated to the Developer's
Reference--after it has been approved through the usual procedure.)
Maintainership
==============
The Debian GNU/Linux distribution is a collection of source and
binary packages. These packages are `maintained' by different Debian
developers, the so-called `package maintainers.'
In most cases, the packages will contain programs written and
maintained be people outside the Debian project, by an `upstream
maintainer.' The source code of these packages is referred to as
`upstream source code.' In opposite, programs written by a Debian
developer for use mainly in the Debian distribution, are called
`native Debian packages.'
Every package in the distribution must have one or more maintainers
at a time (see below).
Duties of a maintainer
----------------------
Being maintainer of a package means the following: (note, that in
some cases a maintainer can not fulfill all these requirements--see
notes below)
- to convert a piece of software into a Debian package (`to package
up a program')
(Usually, this means to package up the upstream source code in a
Debian source package which can be compiled into a binary
package.)
- to adjust and configure the program to comply with the Debian
policy and to cooperate with other programs/packages in the
distribution
(Here, `cooperation' means to not actively work against another
program or package.)
- to handle any bug reports which are filed against the package,
which involves:
- answering arriving bug reports with a short message, saying
that the problem is handled
- checking out the details of a bug (e.g., trying to reproduce
the situation where the problem occurred)
- fixing the bug or forwarding the bug report to the upstream
maintainer (if the maintainer decides to fix the bug
him/herself, he/she should forward the bug-fixing patch to the
upstream maintainer)
- uploading a fixed version of the package
- closing the bug report
- to keep track of new upstream releases of the program and update
the package, if appropriate
- to stay in contact with the upstream maintainer about bugs or
feature requests
(However, in some rare situations an upstream maintainer doesn't
want to be bothered about bugs or feature requests. The decision
whether to contact the upstream maintainer or not in special
situation is left up to the maintainer.)
Privileges of a maintainer
--------------------------
A package maintainer has the following rights:
- make any technical or nontechnical decisions with regard to the
package provided that the decisions don't conflict with policy
requirements
- will be notified and included in any discussions between a
representative developer of the Debian project and the upstream
maintainer of the package
- may delegate any the above duties to any other developer who
volunteers for the task
- may nominate other developers as additional maintainers for the
package
- may hand the package to some other developer who volunteers for
that task
- may choose to drop maintainership of the package and request the
removal of the package from the distribution at any time
In most cases, a package has only one maintainer at a time. This
avoids confusion about who is responsible for a package (i.e., who
has to do the above duties) and who can make final decisions on a
package (i.e., who is granted the rights listed above). This
developer will be called the `Maintainer of the package' and his/her
name is listed in the "Maintainer:" control field (see below for
details).
It's also possible for a package to have several maintainers at a
time, who all share the duties and privileges listed above. One of
these developers has to be nominated as `master maintainer,' who has
the final word in case of conflict situations (e.g., if the different
maintainers disagree on a decision). The names of all these
developers are listed in the "Maintainer:" control field, together
with a common email address (see below).
Interim package releases
------------------------
Under certain circumstances it is necessary for someone other than
the usual package maintainer to make a release of a package.
[include section 4.4 of the Developer's Reference here]
Orphaned packages [first paragraph based on s2.3.2, policy manual]
-----------------
If the maintainer of a package quits from the Debian project, or if
he/she can't do his/her duties as maintainer because he/she's too
busy or unreachable for a long time, the Debian QA Group takes over
the maintainership of the package until someone else volunteers for
that task. Such packages are called `orphaned packages.'
The Debian QA Group can decide to drop less important orphaned
packages from the distribution. In that case, the binary packages
will be removed and the source package will be stored in an extra
directory on the Debian master server (currently,
`project/orphaned'), so that the work of the maintainer is not lost.
The Maintainer control field
----------------------------
Each Debian source and binary package must have a `Maintainer'
control field, which lists the current maintainer(s) of a
package. The source package and all derived binary packages must have
identical Maintainer fields.
The Maintainer control field must have the following form (variable
values are surrounded by "--")
Maintainer: --name-of-maintainer(s)-- <--email-address-->
In addition, this field must represent a valid email address (as
defined by RFC ????).
Though a maintainer may choose to use different email addresses on
his/her packages, the maintainer's name must always be written in
exactly the same way on all his/her packages to allow scripts to
easily detect all packages maintained by one developer.
If a package has multiple maintainers at a time, the names of all
maintainers will be listed in the Maintainer control field, separated
by "and". In addition, an email alias which refers to all developers
has to be listed. The `master maintainer' of a package is listed
first.
---end-of-proposal------------------------------------------------------
Changes WRT current policy:
- removed suggestion that the email addresses should be unique within the
different packages of a maintainer
- added requirement, that the name listed in the Maintainer field is
the same on all packages of that maintainer
- packages are allowed to have several maintainers at once
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Don't know Perl? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: