Hi,
I second the GR proposal quoted below.
Cheers,
Moritz
>=3D=3D=3D=3D Debian Maintainers Proposal =3D=3D=3D=3D
>
> 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
> delegations.
>
> 2) The initial policy for an individual to be included in the keyring
> will be:
>
> * that the applicant acknowledges Debian's social contract,=20
> 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
> provided:
>
> * 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.
>
>=3D=3D=3D=3D Debian Maintainers Proposal =3D=3D=3D=3DAttachment:
signature.asc
Description: Digital signature