Re: first proposal for a new maintainer policy
On Mon, 27 Apr 1998, Ian Jackson wrote:
> Christian Schwarz writes ("first proposal for a new maintainer policy"):
> > 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)
>
> I think you should specify what having a duty means. In particular, I
> think you should state that:
>
> This list of duties and privileges describes the tasks that need to
> be done for proper maintenance of a Debian package, and the
> assistance that others in the Project should provide to people doing
> these tasks.
>
> A developer who is for any reason unable perform some or all their
> duties should say so; the Project will then try to find someone else
> to do the relevant tasks. Such a developer should not be flamed,
> insulted or personally criticised for this.
This is fine with me.
(Does someone else object??)
> ...
> > 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
>
> This directly contradicts the proposed constitution. Now, obviously,
> the policy can say that `foo must be done' and since the policy has no
> authority according to the constitution (the fundamental document
> which grants authority) to override maintainers' decisions we can
> ignore that sentence.
I don't see how this conflicts with the proposed constitution. Please give
me more info on that.
proposed constitution v0.6.1, section 3.1:
`An individual developer may
1. make any techical or nontechnical decision with regard to
their own work;
2. [...]'
I thought `WRT their own work' refers also to the packages someone
maintains.
> However, I think it would be better if we didn't make false things
> policy !
I fully agree!
> ...
> > 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).
>
> I disagree with the `master maintainer' thing. In case of conflict
> which cannot be resolved internally the Technical Committee should
> decide, either before or after both sides have offered a package for
> inclusion.
This solution is fine with me too, but that should be documented in the
policy manual too then (just for completeness). Note, that this will move
some authority from the developers to the technical committee. We'll have
to see which effects this will have... (If the tech-ctte overrules
developers too often, I expect that some developers will give up and
leave. Hope that this will never happen.)
> I also disagree with the requirements for the formatting of the
> Maintainer field.
Why?
The reason why we need this requirement, is that we _have_ to detect
orphaned packages by some automatic procedure. Note, that our distribution
still contains packages from developers who left over a year ago!
The idea was to set up a Developer DB (cf., discussion on debian-private)
and to have Maintainer fields using a special format, so that a script
could check which packages in the archive have maintainers and which are
`orphaned'.
> I agree with whoever was that said that we should mandate _what_ gets
> done, not _how_. The management of package maintainers' internal
> affairs is not the business of policy.
Note, that any requirements about Maintainer fields are _NOT_ about
`internal affairs', but about the `interface' between the group of
maintainers of a package and the project as a whole.
> ...
> > 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-->
>
> The name part should be the name of the maintainer if it is an
> individual, or otherwise a descriptive string.
I strongly disagree! It's important to know which people are maintaining a
package--that's important for the project, for the maintainers, and for
the users.
If you still disagree, please be more specific.
> Incorporate the relevant part of the dpkg manual (which specifies the
> format exactly) by reference or inclusion.
>
> Use a sensible syntax notation, for example
> The Maintainer control field must have the following form
> (metasyntactic variables start with $)
>
> Maintainer: $name <$email_address>
Note, that my whole proposal was clearly marked as `first draft'. The
details will be worked out as soon as we have a rough consensus about a
new policy.
> > In addition, this field must represent a valid email address (as
> > defined by RFC ????).
>
> No, this is not the case. See the dpkg documentation.
A lot of people cut-n-paste the contents of the Maintainer field into
their mail client to send mails to the maintainers. What's the problem
with this requirement?
> > 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.
>
> Make it clear that this only applies to packages maintained by a
> single individual.
>
> > 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.
>
> Cut this paragraph.
No, this was not what I meant (see above).
> ...
> > 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
>
> The Debian QA group still violates this policy, as does owner@bugs,
> new-maintainer, dpkg, &c &c &c.
Note, that when discussing new aspects of policy, we usually don't look
too close on the current situation--instead, we check out what's the best
solution!
Now to your examples:
Debian QA group: The QA group is not a replacement for a maintainer. (I
verified this by asking James Troup, who's, AFAIK, a member of the QA
group.) The group only makes uploads for important bug fixes. Their
packages are still considered `orphaned', and should not become part of a
release. (If a package is too important to be removed, the package should
be taken over by some individual or by a group of maintainers who are
listed `by name' then.)
owner@bugs, new-maintainer: These are not _packages_!
dpkg: The dpkg Maintainer field reads `Klee Dienes and Ian Jackson
<dpkg-maint@chiark.greenend.org.uk>' which is perfectly in
compliance with my proposal for a new maintainer policy!
`&c &c &c': AFAIK, there are no other multi-maintainer packages yet.
(There is only the new keyring package waiting in Incoming/.)
> Please try harder to document existing practice and consensus rather
> than forcing your own ideas of management on everyone !
Ian, I really respect you as project leader, but please let me note that
you have been away for a long time now. From the last comments you sent to
debian-policy, I got the impression that you've missed some major changes
in the project: the project is a lot larger now than it was before, we
have much more consistency problems, and we have a _lot_ more discussions
about technical policy.
I know that you've seen my job rather as `Policy Editor' than as `Policy
Manager', but just documenting `existing practise and consensus' wouldn't
work! Either there is no consensus, or this consensus would conflict with
other aspects of policy. It is very important that there is a common line
for policy (policy shouldn't be self-contradicting, and it should be
logically so that people can see the reasons behind policy and don't have
to look up every single aspect).
So my main job was to `coordinate' policy discussion and try to _actively_
work out a consensus that everyone finally agrees with. (Note, that there
is no `force' involved.) Until now, I've never used my fiat power to
implement new policy.
Thanks,
Chris
-- Christian Schwarz
Do you know schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux? 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.debian.org 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: