Hi,
these are my thoughts on how the NM process could look like in the
future. The proposal has been inspired by Anthony Town's blog posting
at [1], by my own experience in NM and being an AM, and finally by
discussions with Marc Brockschmidt.
[1] http://azure.humbug.org.au/~aj/blog/2006/04/12#2006-04-11-maintainers
Let's summarize the current process first:
1. ITP, package created, sponsored
2. work on the package (bug fixing, new upstream releases)
3. (hopefully) more contribution like other packages, patches, other
projects
4. advocate, NM application
5. wait for AM
6. NM process
7. wait for DAM
There are some problems with that, mostly summarized by Marc in his
d-d-a posting [2] and the following thread on -project, so I won't
repeat them here.
[2] http://lists.debian.org/debian-devel-announce/2006/04/msg00006.html
Here's my proposal:
+---------
| Introduce an intermediate role "Debian Maintainer" (DM).
| Summary: is allowed to upload packages already in the archive by himself.
| Needs sponsoring for new packages, no vote rights. Can either proceed to
| become DD or stay a DM.
+---------
The intention is to create an intermediate role that people can get in
easier/earlier that allows them to learn. The expectation is that some
people will stay here if they are happy with uploading their packages.
At the same time, the people applying for "full" DD are more
experienced, and hence create less load on AMs. Most non-capable
candidates will be filtered out in the DM checks. At the same time,
people get (restricted) upload rights earlier, such that the following
DD process does not delay them that much from working on their packages.
The difference to Anthony's proposal is that I don't want to kill
sponsoring. Sponsoring has worked quite well so far, as it includes both
review by an experienced developer and gets people in touch with the
project. Also, I want an application manager to handle the application
and not just use a simple mail bot to make sure people have at least a
basic knowledge. This "DM process" should be as light-weight as
possible.
The process I propose looks like:
Stage 0:
1. ITP, package created, sponsored
-> same as before
2. contributes to Debian:
-> work on the package (bug fixing, new upstream releases) with
sponsored uploads
-> 2nd package with >> 1 upload (e.g. not a totally trivial package,
a rule of thumb could be like at least 6 uploads for all packages
in total)
-> some other contributions (e.g. bugs on other packages)
-> the applicant should contribute for a minimum of 3 months before
actually applying.
Stage 1:
3. get an advocate, apply for DM
4. AM assigned (much faster (hopefully [1]))
5. DM process
-> ID check (DD signature)
-> light version of the classical NM templates
should be only a few kB, 1 mail
6. can use his gpg key to upload this package [2]
-> no account/@d.o address yet
-> every upload which would go to NEW needs a sponsor [3,4]
7. continuous contribution, one or more of:
-> other packages
-> bug reports with patches
-> other projects
-> the intention here is that the DM has to show interest in the
project beyond his own small set of packages before applying for
DD
-> again minimum of 3 months
Stage 2:
8. advocate [5], DD application
9. wait for AM (again, hopefully shorter) [6]
10. DD process
-> redesign of the DD process is a different topic
11. wait for DAM
12. may vote/upload/NMU/log in/whatever
Discussion, notes:
[1] that's why we are doing all this :)
[2] new keyring (maintained by keyring-maint) that includes mapping
keyid <-> maintainer address, katie only accepts uploads from that
keyring when the maintainer address matches.
[3] Do we allow existing sources with new binaries to go to new?
(Library renames etc.)
-> has to be discussed
[4] new source packages can probably be automatically enabled for a DM
using the keyid <-> address mapping (alternatively, use a mail robot
fed by the sponsor)
[5] Do we require a different advocate? (Should be no problem at that
stage, but is an additional burden.)
[6] Require a different AM?
Some random other notes:
Names: Changing the term "Debian Developer" is impossible. The term
"Debian Maintainer" says what the people will do, and sounds nice. The
proposed term "Debian Contributor" and similar proposals sound too
much like "they do stuff, but that's not the real thing".
dpkg: Should we introduce a new Signed-By (Built-By?) field in the
.changes? (As by Anthony's observation that it's hard to see who
sponsored which upload.)
Thanks go to Marc Brockschmidt who provided feedback on this draft.
If you are at DebConf, there will be 2 related BoFs: one at Friday
morning where we will discuss current AM work to talk about experience
and how we are handling stuff, and one at Friday noon where I want to
discuss the NM process future (i.e. this proposal and other ideas). If
you are an (D)AM, currently in NM, plan to apply, applied earlier, or
just interested in the topic in general, please join us.
Christoph
Attachment:
signature.asc
Description: Digital signature