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

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


first: thank you. Recent threads show, we clearly need a discussion like
this and hopefully people will take it as an opportunity to leave this
thread a bit more enlightened.

On 13.06.2012 17:35, Ian Jackson wrote:
>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.

A DM can't upload anything, just because of his being as a DM. It's the
uploader field AND the DMUA flag which matters. So, if you don't trust a
person to upload packages, don't set the flag.

Since that's per package and not per person and package, this might have
some side effects, but Ansgar is about to change that, so we do not need
to worry too much about that (again).

> c. Who is entitled to prepare a non-NMU upload of the package.
>    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.

By the way, for a sponsored maintainer there is no trusted evidence at
all whether you are sponsoring an upload of said person or of an impostor.

Drive-by sponsoring makes this even more complicated and is not helping
anybody. We should stop advocating drive-by sponsoring at all.

1) You upload a package without feeling responsible for it over a longer
term. Thus, that package is virtually stuck forever as is in Debian
because ...
2) ... Drive-by sponsoring does not work. It's annoying and
back-breaking to the sponsored maintainer to have a package containing
lots of fixes and maybe a new upstream version but nobody which uploads
the you've been working on (yes, that happens)
3) It's not helpful because the sponsor, at best, has a rough and
cursory understanding how the package works.
4) It's not clear at all how a bug fix could be uploaded to Debian at
all, so the package might be in bad shape soon as nobody who /could/
upload feels responsible for it and those who care /can't/ upload.

> f. Are there specific things that an NMUer should watch out for ?
>    Currently we have no general way of finding these.  The closes is
>    the LowThresholdNmu wiki page.

There clearly are. Just read

And hopefully some other people regularly sponsoring or doing themselves
unacceptable NMUs do so as well.

>  * Individual DD or DM maintainer, perhaps with co-maintainers.  The
>    single individual principal maintainer is listed in Maintainer and
>    makes all decisions.  Co-maintainers are listed in Uploaders and
>    may make their own uploads and may in general make decisions where
>    not contradicted by the principal maintainer.  There may or may not
>    be any information for NMUers.

I do not like that idea of introducing more and less important people
and classes for a package. That's against our spirit. However, as I said
in IRC: De-facto that's the case for a long time already, so be it for
the sake of just stopping to trick ourselves here.

I think that part of your suggestion is improvable, though. After all I
do not think there is (should be) any difference in authority at all -
whether someone is listed as a maintainer or as a uploader does not
matter to me. The rationale for the Uploader field is a technical one
and has nothing to do with actual powers. It clearly should have been
named different, however.

> 1. Change the definition of the Maintainer field to permit multiple
>    entries.

There were probably technical reasons back then when introducing
Uploaders. Maybe someone knows.

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

That would be a sad day for Debian as a whole because it introduces a
class society within Debian. But again, de-facto that's a truth already.

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

That's a good idea I like.

> 5. Introduce a new conventional location for information useful to
>    NMUers,
>       debian/README.nmu


Maybe we could stick both, the maintainer and the NMU information
README.source though, as people suggested in IRC.

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

There are lots of reason if you look into the dak source and check how
exactly DM upload permissions are hacked into it.

with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: