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

[Gergely Nagy <algernon@balabit.hu>]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> So for example, DDs have enormous theoretical power but there are
> strong and well documented social controls on how they should exercise
> that.  I think as a matter of principle that the same principle should
> apply to DMs: it is easy to remove a misbehaving DM from Uploaders.

For some values of easy. It requires a sourceful upload for possibly no
other reason than to remove an uploader. That's a waste of time, not
only for the maintainers, but the buildds and archive software too.

Would the package take long to compile, it would be even worse.

We can't compare this to the case of DD's, because DD upload rights are
only governed by social customs and the keyring, the DMs have
*additional* restrictions, which currently are tied to the source
package.

> So it is not necessary to have technical measures that prevent a DM
> mentioned in Uploaders from violating the package's uploading rules,
> bypassing review processes, or whatever.  Instead, when a package team
> or lead maintainer accepts someone into Uploaders we should clearly
> communicate to the new uploader what is expected of them, and then we
> should trust them to do as we have asked.

Well, one of the reasons DMs are not DDs, is because they do not have
the same rights as DDs do: they can't, and in my opinion, shouldn't be
able to upload pretty much any package without further restrictions. If
they would, they'd technically have the same upload rights as DDs do,
with a fraction of the experience, and without going through NM. I don't
think that would be wise. (No disprespect meant for DMs, mind you)

However, this (whether we need the extra upload restrictions for DMs), I
believe is not strictly related to the proposal, which, to my reading,
was more about moving the DM-Allowed field out of the source package,
and a few other things.

> The questions that need to be answered for a package are:
[..]
>  * Who makes final decisions about the package; this includes
>    arbitraring disputes, delegating authority, revoking such
>    delegation, etc.
[...]
>    I'm going to call these people the maintainers of the package.
>    They might be DDs, DMs, or contributors without a key in the
>    keyring.
>
>    Currently this information is sometimes in the Maintainer field;
>    sometimes in both the Uploaders and Maintainers fields; and
>    sometimes somewhere else completely (eg a team wiki page).
>
>    Normally the maintainers would be the people who are doing most of
>    the work.  Sometimes we have provisional maintainers who are
>    neither DD or DM; in those cases the maintainer works under the
>    supervision of their sponsors.

So far, I agree.

> c. Who is entitled to prepare a non-NMU upload of the package.
>
>    This information needs to be accessible to the project as a whole.
>
>    Particularly a potential drive-by sponsor needs to know whether the
>    upload they are sponsoring is by someone entitled to prepare such
>    an upload.  And the archive software needs to know whether to
>    permit an upload.
>
>    Currently this information is sometimes in the Maintainer field;
>    sometimes in both the Uploaders and Maintainers fields; and
>    sometimes somewhere else completely (eg a team wiki page).

There's also the case of DM-Allowed: yes. If someone is listed as
maintainer, but is not a DD, then my understanding is, that he is not
entitled to upload. (Hence, should not be in Uploaders, either, unless
DM-Allowed: yes is set)

This looks silly, though, and inconsistent, and very easy to miss when
sponsoring or working within a larger team.

Nevertheless, in case the maintainer is not a DD, he either needs a
sponsor, or must be a DM, with the package having DM-Allowed: yes. This
also presents a problem when adopting packages, because if the adopter
is a DM, someone must sponsor his first upload or set DM-Allowed: yes
otherwise in a separate upload - neither of which is particularly
friendly towards the DM (nor anyone else, really).

Would this restriction get untied from the source, the former maintainer
could grant upload rights without having to do a sourceful upload, and
everyone wins, and no rights get harmed either.

> e. What process should someone preparing a non-NMU upload follow?
>
>    Eg, is there a VCS that everything should be committed to ?  Are
>    non-emergency uploads supposed to be reviewed somewhere ?  Are some
>    of the people who are entitled to upload supposed only to do so
>    after explicit indication by someone more senior that they should
>    do so ?
>
>    Again this information doesn't generally need to be available to
>    people outside the packaging team.  However, if there are
>    significant and important processes that should be followed, a
>    drive-by sponsor should be able to find them easily so that they
>    can double-check that the person preparing the upload (the sponsee)
>    seems to be doing the right thing.
>
>    Currently this information is, if available at all, to be found on
>    various team wiki pages etc. which may be hard to discover.

There's Vcs-* and debian/README.source to help with this situation. All
of the above can - and in my opinion, should be - added to all packages
where it is relevant, team maintained or not. At worst, a pointer to a
wiki or similar.

> g. For a package in alioth collab-maint, how is the VCS workflow
>    organised and who is expected to push to which branches ?
>
>    Currently we have no general way of finding these.

The workflow and branch setup should either be trivial to guess (eg, it
follows gbp defaults), or documented in debian/README.source.

> As an example of some common patterns:
[...]

I'd like to list a few more cases, which may not be as common as the
rest, but are nevertheless interesting, and with the proposal in mind,
relevant:

 * DM maintainer, no uploaders, no co-maintainers, no team.

   The maintainer is only allowed to upload when the *previous* version
   of the package had DM-Allowed: yes, which means he can't upload new
   packages himself, without a sponsor.

   It also means that a DM can't adopt and upload a package which did
   not have DM-Allowed: yes set previously. Someone, possibly the
   previous maintainer (or a sponsor, but rather the previous
   maintainer) needs to set that flag.

   That flag currently requires a sourceful upload, and makes things
   like the above two cases, awkward and unfriendly.

>  * Individual non-DM maintainer, co-maintainers including at least one
>    usual DD or DM sponsor.  The maintainer is listed in Maintainer;
>    the usual sponsor(s) are listed in Uploaders.  The principal
>    maintainer makes decisons as before; however their authority is
>    weakened by their inability to upload without sponsorship.  In
>    practice this means that the principal maintainer does the work but
>    the co-maintainers have supervisory authority.

This is somewhat similar to the example I outlined above, as the same
situation happens when the maintainer is DM, but the package does not
have DM-Allowed: yes.

> I think the key problems we have here are:
>
>  * The relative seniority of members of Maintainer vs Uploaders is not
>    always clear.  This is complicated by the fact that it is not
>    possible to list more than one person in Maintainers.

The problem is that there can only be a single Maintainer, so
co-maintainers (either of equal or lesser seniority) must all be
shoveled into Uploaders.

That is unfortunate, as we can't see who has the seniority just by
looking at these two fields (as an Uploader might very well be of equal
standing, but due to technical limitations, is not listed in
Maintainer).

>  * We do not have a common understanding of who is entitled to hijack
>    a package and when they are entitled to do so.  This is a hard and
>    controversial problem which deserves considering on its own, and
>    will be a distraction for what I'm saying in this message.

This is another thing that deserves a separate discussion (or even
better, no discussion at all, but a case-by-case handling when the need
arises). It should not be thrown together with discussions about DM
uploads.

> 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.

Completely agreed!

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

Sounds reasonable too.

>    Uploaders merely implies authority to prepare an new version, and
>    if the listed person is capable of doing so, upload it.
>
>    Explicitly state that the authority of Uploaders to prepare and
>    upload is subject always to the contents of debian/README.maintain.

I wouldn't introduce a new file for this. Since preparing an upload
involves changing the source, we could use debian/README.source to
explain the workflow used for packaging (including responsibilities,
etc).

I think that would fit into debian/README.source nicely.

> 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.

See above: debian/README.source could be repurposed to document
everything related to the source: how to get it, how to prepare it, the
workflow used, responsibilties and whatever other guidelines the
maintainers see appropriate.

> 5. Introduce a new conventional location for information useful to
>    NMUers,
>       debian/README.nmu
>
>    Explicitly state that someone preparing or sponsoring an NMU should
>    consult this file.  Statements in this file may supplement, but do
>    not overrule, the NMU criteria established by the Developers'
>    Reference, by the release team, or elsewhere.
>
>    Explicitly state that NMUers are NOT necessarily required to
>    consult README.maintain.

I don't see how this would be useful...?

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

I do. Not to limit their rights, but to make it easier for both DMs and
DDs to work efficiently. Being tied to "DM-Allowed: yes" *sucks*, very
much.

No matter what process you think up, no matter how well responsibilities
and whatnot are documented, as long as DM-Allowed: yes works as it does
today, things will be broken. The proposal posted earlier solved all of
the problems I see with the flag in a neat and elegant way.

I'm afraid none of your ideas above does any good for any of the cases I
care about, as it does not address the root problem: uploads by DMs are
currently tied to DM-Allowed being set in a previous upload. Otherwise,
they can't upload.

-- 
|8]