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

Re: Debian Maintainers GR Proposal



I second the proposal below. 

It looks like a sensible policy and anyway the policy can evolve over
time. The team handling the keyring should be able to adjust it as we
discover how to best handle this new class of contributors.

Cheers,

On Thu, 21 Jun 2007, Anthony Towns wrote:
> ==== Debian Maintainers Proposal ====
> 
> The Debian Project endorses the concept of "Debian Maintainers" with
> limited access, and resolves to 
> 
> 1) A new keyring will be created, called the "Debian maintainers keyring".
>    It will be initially maintained in alioth subversion using the jetring
>    tool, with commit priveleges initially assigned to:
> 
> 	* the Debian Account Managers (Joerg Jaspert, James Troup)
> 	* the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt, 
> 	  Brian Nelson)
> 	* the FTP masters (James Troup, Ryan Murray, Anthony Towns)
> 	* the Debian Keyring maintenaners (James Troup, Michael Beattie)
> 	* the Jetring developers (Joey Hess, Anthony Towns, Christoph Berg)
> 
>    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.
> 
>    The keyring will be packaged for Debian, and regularly uploaded
>    to unstable.
> 
> 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 (preferable more) is willing
> 	  to advocate for the applicant's inclusion, in particular to the
> 	  fact 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 for removals for the keyring will be 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 non-spurious reasons; eg, due to problematic
> 	  uploads, unfixed bugs, or being unreasonably difficult to
> 	  work with.
> 	* the Debian Account Managers have requested the individual's
> 	  removal for any reason.
> 
> 4) The initial policy for Debian developers who wish to advocate
>    a potential Debian maintainer will be:
> 
> 	* Developers should take care in who 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 matches the
> 	  key used (ie, 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 lists the uploader in the Maintainer: or Uploaders:
> 	  fields (ie, 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.
> 
> Cheers,
> aj
> 



-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Attachment: signature.asc
Description: Digital signature


Reply to: