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

Re: Debian Maintainers GR Proposal, updated

I second the proposal below.

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

* toresbe wonders what would happen if Ted Walther and Amaya were put in the
	same room
<Amaya> toresbe: blood, sweat, tears and finally castration

Attachment: signature.asc
Description: Digital signature

Reply to: