Re: Debian Maintainers GR Proposal
Kalle Kivimaa wrote:
> I second the following proposal (by my count it is still missing at
> least two seconds, if anybody is interested in seconding).
I believe it has way to many flaws to be seconded.
> ==== 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)
It would be nice to know what the DAMs think about this, especially
James, since he's one of the reasons this proposal came up since
the last stage before account creation takes oh so long. If he's
totally opposed to this proposal, I'm not sure how much value it
has at all.
> * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt,
> Brian Nelson)
> * the FTP masters (James Troup, Ryan Murray, Anthony Towns)
It would be nice to know what the FTP masters think about this proposal
(the others, not Anthony).
> * the Debian Keyring maintenaners (James Troup, Michael Beattie)
> * the Jetring developers (Joey Hess, Anthony Towns, Christoph Berg)
The maintainer of software initially used should not per se have
commit rights and decide who is granted. They should have proper
rights to maintain the software which others are free to use, but
> 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
That "and" may require to be substituted into an "or".
> 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
> * 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)
Should read "matches the address and name of the key used", I don't
want to have GPG keys used in the maintainer field please!
> * 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
I'm missing any mention about taking over arbitrary packages since it
was said that a DM can not simply upload arbitrary packages but is
only permitted to upload them they came up initially and which were reviewed.
I still believe that this proposal is flawed and we should address the
real issue it secretly tries to solve.
We should instead grant NM applicants permission to upload the
packages they work on during their NMship *after* their AM has
reviewed the packages and *after* they have demonstated to be
competent enough to properly maintain them, even before they have
finished NM and are only waiting for DAM activity.
It may also be worth re-evaluating NM with regards to the difficulty
and relevance of questions NM applicants have to answer correctly.
Should it turn out that we want too much, we may alter the process a
We should not install the DM thingy in the proposed form.
Given enough thrust pigs will fly, but it's not necessarily a good idea.