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

Re: Debian Maintainers GR Proposal, updated

On Wed, Jun 27, 2007 at 12:41:35PM +0100, Anthony Towns wrote:
>==== 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
>   delegations.
>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
>   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.
>==== Debian Maintainers Proposal ====
>Seconds, comments or amendments appreciated.


Aníbal Monsalve Salazar

Attachment: signature.asc
Description: Digital signature

Reply to: