I second the proposal below. Cheers,
On Wed, 27 Jun 2007, 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. > > Cheers, > aj > -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
signature.asc
Description: Digital signature
