Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Ansgar Burchardt <ansgar@debian.org>]

Hi,

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> I think the first three can be fixed relatively simply.  I propose the
> following changes:
>
> 1. Change the definition of the Maintainer field to permit multiple
>    entries.
>
>    There are currently four different entities (3 humans and a
>    corporation) which use a comma in a Maintainer field, in only 13
>    different source packages.  None of these commas are essential to
>    comprehension (indeed in principle those same entities might have
>    to have variants of their identification without commas, suitable
>    for use in Uploaders).  All but one of these Maintainer fields are
>    already violations of policy 5.6.2 which says that the Maintainer
>    field must be in "RFC822 format" (a bit vague, but clearly excludes
>    bare commas).
>
>    So this is an easy change.

This was suggested when the Uploaders field was originally introduced,
but not done in order to avoid breaking tools that rely on having only
one entry in the Maintainer field[1].

  [1] <http://bugs.debian.org/101815>

I find it also interesting to note that Uploaders was originally called
Maintainers in said bug report.

> 2. Explicitly state that being listed in Uploaders does not in itself
>    imply general authority over the package; general authority is
>    reserved to maintainers.

I disagree with this quite strongly: while it may be current practice
that some maintainers have more to say about a particular package than
other maintainers, this is currently part of the *private* relation
between maintainers.  To outsiders they can (and should!) still be
peers.

Your suggested change would instead formally introduce 2nd class
maintainers which I would not like to endorse.  I do not think I would
have felt as welcome in Debian as I did if this had been the case.

> 3. Introduce a new conventional location for information about a
>    maintenance team and a package's maintenance practices,
>       debian/README.maintain
>    in the source package.
>
[...]
>
> 5. Introduce a new conventional location for information useful to
>    NMUers,
>       debian/README.nmu

I think this information could be located in README.source just as
well.

> It doesn't seem to me that there is any need to change the archive
> machinery to handle DM permissions differently.

I am still not sure what you find so bad about the proposed changes.
But let's go through all changes to try and keep everyone happy:

a, Drop the requirement that DMs cannot sponsor packages they can upload
   themselves.

b, Identify DMs by fingerprint instead of name/mail. This is how dak
   sees everyone else and avoids problems with multiple uids (as dak
   only knows about one of them).

c, Move the DM-U-A flag to projectb instead of the source package. Also
   use an explicit list for upload permissions instead of having it
   implied by Maintainer/Uploaders (which we need anyway as we want to
   use fingerprints).

d, Allow *only* DDs to change upload permissions.

   This is unrelated to the other changes.  We could technically allow
   DMs that have upload privileges for a package to grant that to others
   as well, but I do not believe this to be intended by the DM concept.

None of these changes are intended to take anything away from DMs which
I get the impression you believe.  a, and b, certainly don't as we drop
some restrictions currently implemented in dak.  c, is mostly a change
how DM is implemented; it also allows a DD to grant upload permissions
to multiple packages at once when he is convinced the DM can handle
them (eg. a group of similar or closely related packages).

I also don't believe d, should be a large problem for DMs in
practice.  They should already know a DD they can ask to set DM-U-A for
them just as they would need for a package where the other maintainer
was not already a DM.

In fact your proposed changes might be more restrictive to both DMs and
non-D[DM] maintainers as it makes it harder for them to find sponsors
when they are "only" listed in Uploaders.  We already don't have enough
people mentoring others and I doubt having them check additional things
(May an Uploader change source format for this package? May he switch
packaging tools? ...) would bring improvements.

Regards,
Ansgar