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

Re: Debian Maintainers GR Proposal, updated

On 6/27/07, Anthony Towns <aj@azure.humbug.org.au> wrote:
Okay, here's a new draft with the following changes:

    - incorporate committers by name rather than by relevant

    - split committers into expected active committers and reserve

    - mention tools expected to be used, but don't require them even

    - add DM-Upload-Allowed: field to prevent existing sponsored
      contributors mentioned in Maintainer/Uploaders: fields from being
      automatically authorised to upload those packages should they
      become a non-DD maintainer under this process

    - various grammar/language improvements

For those who haven't followed the thread prior to this post, it might
be worth also reading the sample use cases in the sub-thread beginning:

    Message-ID: <20070625184520.GC17841@azure.humbug.org.au>

Note that those are possible uses, and the detailed policies for them
would presumably continue to be developed rather than being fixed now.

==== Debian Maintainers Proposal ====

The Debian Project endorses the concept of "Debian Maintainers" with
limited access, and resolves that:

1) A new keyring will be created, called the "Debian maintainers keyring".
   It will be initially maintained by:

        * Anthony Towns (proposer, ftpmaster, jetring developer)
        * Joey Hess (jetring developer)

   Commit access will also be provided to others in Debian with similar
   roles to ensure that any problems relating to this keyring can be
   dealt with by multiple people. These people will initially be:

        * Brian Nelson (n-m frontdesk)
        * Christoph Berg (n-m frontdesk, jetring developer)
        * James Troup (DAM, ftpmaster, keyring-maint)
        * Joerg Jaspert (DAM)
        * Marc Brockschmidt (n-m frontdesk)
        * Michael Beattie (keyring-maint)
        * Ryan Murray (ftpmaster)

   The keyring will be handled using suitable technology to ensure it
   can be maintained by a team. It is expected it will initially be
   maintained in alioth subversion using the jetring tool, and that the
   keyring will be packaged for Debian and regularly uploaded to unstable.

   The team will be known as the Debian Maintainer Keyring team. Changes
   to the team may be made by the DPL under the normal rules for

2) The initial policy for an individual to be included in the keyring
   will be:

        * that the applicant acknowledges Debian's social contract,
          free software guidelines, and machine usage policies.

        * that the applicant provides a valid gpg key, signed by a
          Debian developer (and preferably connected to the web of
          trust by multiple paths).

        * that at least one Debian developer (preferably more) is willing
          to advocate the applicant's inclusion, in particular that the
          applicant is technically competent and good to work with.

   All additions to the keyring will be publicly announced to the
   debian-project list.

3) The initial policy is that removals from the keyring will occur under
   any of the following circumstances:

        * the individual has become a Debian developer
        * the individual has not annually reconfirmed their interest
        * multiple Debian developers have requested the individual's
          removal for good reason, such as problematic uploads, unfixed
          bugs, or being unreasonably difficult to work with.
        * the Debian Account Managers have requested the removal

4) The initial policy for Debian developers who wish to advocate
   a potential Debian maintainer will be:

        * Developers should take care whom they choose to advocate,
          particularly if they have not successfully participated as an
          Application Manager, or in other mentoring roles. Advocacy should
          only come after seeing the individual working effectively within
          Debian, both technically and socially.

        * Advocacy messages should be posted to debian-newmaint or
          other relevant public mailing list, and a link to that mail
          provided with the application.

        * If a developer repeatedly advocates individuals who cause
          problems and need to be removed, the Debian Maintainer Keyring
          team may stop accepting advocacy from that developer. If the
          advocacy appears to be malicious or particularly careless, the
          Debian Account Managers may consider removing that developer
          from the project.

5) The intial policy for the use of the Debian Maintainer keyring with the
   Debian archive will be to accept uploads signed by a key in that keyring

        * none of the uploaded packages are NEW

        * the Maintainer: field of the uploaded .changes file corresponds
          with the owner of the key used (ie, non-developer maintainers
          may not sponsor uploads)

        * none of the packages are being taken over from other source packages

        * the most recent version of the package uploaded to unstable or
          experimental includes the field "DM-Upload-Allowed: yes"
          in the source section of its control file.

        * the most recent version of the package uploaded to unstable
          or experimental lists the uploader in the Maintainer: or Uploaders:
          fields (ie, non-developer maintainers cannot NMU or hijack packages)

        * the usual checks applied to uploads from Debian developers pass

6) The initial relationship to the existing new-maintainer (n-m) procedure
   will be as an independent means of contributing to Debian. This means,
   among other things, that:

        * Applicants in the n-m queue may choose to apply to be a Debian
          maintainer while finishing their application or waiting for
          it to be accepted.

        * Individuals may apply to the n-m process, and pass through it
          without becoming a Debian maintainer at any point.

        * Individuals may apply to become a Debian Maintainer without being
          in the n-m queue, or having any intention of joining the n-m queue.

        * Appication Managers may advocate their n-m applicants but
          are not required to. They may decide to only advocate applicants
          who have passed some (or all) of the T&S or P&P checks.

7) There is no initial policy or plans for use of the keyring outside
   the archive. Individuals who wish to reuse the keyring for granting
   access to services to some or all Debian Maintainers may do so
   according to their own judgement, of course.

   In particular, this means that Debian maintainers do not participate
   in the general resolution procedure defined in the Debian constitution,
   and cannot vote in Debian elections.

==== Debian Maintainers Proposal ====

Seconds, comments or amendments appreciated.

My amendment proposal is:

-         * none of the uploaded packages are NEW

From my four years experience waiting for DAM on the NM queue I think
I've enough credentials to know the difference of let the line above
slip in as it's, and I don't see the line removal adding any trouble
to the project or to the ftpmasters that will still review these NEW
uploads anyway.

In other words, a NEW upload from a DM is safer in a lot of ways than
a regular upload and if we trust the person to the second, why not to
the former ? Remember that we've a lot of newcomers joining important
teams and that they do a lot of the hard work and sometimes the
contribution is blocked by a DD busy with IRL issues or other team and
due to this he can't upload that exact NEW package.

-- stratus
get debian @ http://get.debian.net/

Reply to: