Hi mates I'd like to offer an alternative gr proposal. I read the whole thread (took me most of the night :( ) and after some discussions on IRC, I come up with this proposal.
I took ajs proposal and modified it to fit my understanding of DM. See the
patch below the proposal, together with my comments for more information.
I avoid repeating most of the arguments, which were send several times in
dozens of mails. This is just my proposal and let's see, if some people want
to support it, or if we just forget about it :)
==== 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:
* the Debian Account Managers (Joerg Jaspert, James Troup)
* the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt,
Brian Nelson)
* the Debian Keyring maintenaners (James Troup, Michael Beattie)
It will be known as the normal people behind the NM process.
Changes to the team may be made by the DPL under the normal rules for
delegations or if the teams accept new members.
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 (preferably more) is willing
to advocate the applicant's inclusion, in particular that the
applicant is technically competent and good to work with.
* that the applicant has to go through an NM process
(this means the ID check and the most important parts of P&P and T&S
have to be done, the AM needs to recommend the NM and FD needs to
check
whether the report is complete or not)
(Note: If the NM applies for DD status, he can become a DM after FD approval)
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
* 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 DM status can be seen as an improvement of the NM process. It is
totally
integrated into the process.
* Applicants can apply to become a Debian maintainer, without becoming
a Debian developer.
* Applicants can still apply to the n-m process, and pass through it
without becoming a Debian maintainer at any point.
* Application Managers may recommend the NMs, who are waiting for the
DAM approval to become a DM after FD approval.
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 ====
--- dm.old 2007-07-05 14:02:02.000000000 +0200
+++ dm 2007-07-05 14:01:30.000000000 +0200
@@ -6,29 +6,19 @@
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.
+ * the Debian Account Managers (Joerg Jaspert, James Troup)
+ * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt,
+ Brian Nelson)
+ * the Debian Keyring maintenaners (James Troup, Michael Beattie)
+
+ It will be known as the normal people behind the NM process.
+ Changes to the team may be made by the DPL under the normal rules for
+ delegations or if the teams accept new members.
+
+ The keyring will be packaged for Debian, and regularly uploaded
+ to unstable.
+
#Please note that I personally do not have any problems with the people aj
#proposed (on the contrary). But as you can see from my proposal, the DM
#thing should be integrated into the NM process and therefore I decided to
#propose that the people already involded in NM (plus keyring-maint, where
#we have a false positive anyway) should do the job. Of course, other people
#can be added.
2) The initial policy for an individual to be included in the keyring
will be:
@@ -44,6 +34,14 @@
to advocate the applicant's inclusion, in particular that the
applicant is technically competent and good to work with.
+ * that the applicant has to go through an NM process
+ (this means the ID check and the most important parts of P&P and
T&S
+ have to be done, the AM needs to recommend the NM and FD needs to
check
+ whether the report is complete or not)
+
+(Note: If the NM applies for DD status, he can become a DM after FD approval)
+
+
All additions to the keyring will be publicly announced to the
debian-project list.
@@ -51,7 +49,6 @@
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.
#We do not expect that part from DDs and I personally just see no point in
#expecting it from DMs. The MIA team and other procedures will IMHO take
#care of this case.
@@ -99,23 +96,17 @@
* 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.
+6) The DM status can be seen as an improvement of the NM process. It is
totally
+ integrated into the process.
- * Individuals may apply to the n-m process, and pass through it
- without becoming a Debian maintainer at any point.
+ * Applicants can apply to become a Debian maintainer, without
becoming
+ a Debian developer.
- * 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.
+ * Applicants can still apply to the n-m process, and pass through it
+ without becoming a Debian maintainer at any point.
- * 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.
+ * Application Managers may recommend the NMs, who are waiting for the
+ DAM approval to become a DM after FD approval.
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
#Here I connect it with the NM process. Note that people can apply for just
#becoming a DM, so DM is not only a stage between NM and DD.
These are my 2cents, somebody around who wants to second it?
Cheers
Steffen
P.S. Please note that I will relocate back to Melbourne soon and therefore I
might be offline for a few days. Just in case you want to ask/answer/blame
me ;)
P.P.S. I apologize for any bad wording and if there are any major typos, ... I
will be more than willing to accept patches.
signature.asc
Description: This is a digitally signed message part.
