Re: Debian Maintainers GR Proposal
Anthony Towns <aj@azure.humbug.org.au> wrote: [...]
> The Debian Project endorses the concept of "Debian Maintainers" with
> limited access, and resolves to
s/resolves to/resolves/ # "resolves to a new keyring will be created"?
> 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:
s/be initially maintained/initially be maintained/ # grr, adverb!
s/be.*, with/have/ # I don't think method should be specified that much.
s/priveleges/privileges/ # unless other countries spell it like that
> * 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)
/Jetring/d # Why should they get those powers?
>
> 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.
s/, and/ and/ # no , needed in front of and
s/regularly // # meaningless - specify frequency if required
> 2) The initial policy for an individual to be included in the keyring
> will be:
>
> * that the applicant acknowledges Debian's social contract,
s/acknowledges/accepts/ # is this what is meant?
> free software guidelines, and machine usage policies.
s/, free software guidelines,/ # part of the SC anyway
> * 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
s/preferable/preferably/
> to advocate for the applicant's inclusion, in particular to the
s/advocate for/advocate/
s/to the fact// # not needed
> 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:
s/under any of/to remove a maintainer in/ # above doesn't make sense to me
>
> * 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.
s/the individual's// # not needed
s/non-spurious reasons.*work with/good reason, such as poor uploads, \
failing to fix bugs, going MIA or being banned from debian services./
# I think any "unreasonably difficult" should get banned elsewhere.
> * the Debian Account Managers have requested the individual's
> removal for any reason.
s/the individual's// # not needed
>
> 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,
s/in who/about who/
> 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.
s/Advocacy should.*technically and socially.//
# I don't really like this paragraph because it is not instructive, but
# the second sentance is bad advice IMO. It is worse than the NM
# advice for advocates, suggesting it's OK to advocate a DM just because
# they can operate in our current somewhat dysfunctional social mix.
> * 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)
s/(ie.*)/
# That's not all being in Maintainer stops: co-maintenance?
> * 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.
In general, I think this is a useful step in the right direction
towards reforming NM into something that doesn't waste so much time.
I hope that you accept the above-suggested amendments and await the
repost.
Regards,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: