On Thu, Jun 21, 2007 at 02:50:59PM +0100, Anthony Towns wrote:
> So here's a proposal for the Debian Maintainers idea that's been floating
> around for some time now [...]
> I've used terms like "initial policy" quite a bit -- [...]
Shortly before leaving DebConf someone (whose name I've forgotten,
sadly) suggested that some sample use cases for the DM process might be
useful. Here's some that come to my mind:
== N-M queue =================
Depending on the AM and the existing experience of the n-m applicant,
the n-m process can be an extended journey -- while some people are
recommended to DAM within a week of being assigned an AM [0], for others
it can be a multiple-month learning experience [1]. For maintainers who
need to do n-m over an extended period, it becomes possible for the AM to
structure the process as:
- Basic introduction to Debian
- Ensure applicant has skills to maintain packages in their
area via sponsored uploads and other questions
- Have applicant become a DM
- Ensure applicant understands more complicated aspects of Debian
through direct participation in Debian as a DM and further discussion
and questions
- Recommend applicant to DAM
making the process more practical and relevant to the applicant, and
giving the AM more confidence that the applicant has practical abilities
rather than just theoretical before handing off to the DAM.
Authorised by: AM
[0] https://nm.debian.org/nmstatus.php?email=pierre.habouzit%40m4x.org
[1] http://lists.debian.org/debian-women/2004/08/msg00126.html
http://lists.debian.org/debian-women/2004/10/msg00017.html
http://lists.debian.org/debian-women/2004/12/msg00056.html
http://lists.debian.org/debian-women/2004/12/msg00179.html
http://lists.debian.org/debian-women/2005/01/msg00029.html
== Sponsored Maintainers =====
For packages that're maintained by non-DDs on an ongoing basis via
sponsored uploads, DM status provides the sponsor with the opportunity
to change the upload priveleges from "default-deny" to "default-allow"
once they are suitably confident that the maintainer is competent and
not malicious, and for the package to be co-maintained by the sponsor and
non-DD as a team. The particular benefits are: the ability for the non-DD
maintainer to make uploads to correct bugs immediately without having
to sync with their sponsor, the ability for the non-DD to gain further
experience with Debian that would otherwise be difficult to obtain and
potentially to be inspired to become a DD, and less load on the sponsor
freeing up more time for other Debian-related tasks, such as higher-level
mentoring with the non-DD maintainer or work on other packages.
Authorised by: Sponsor
Notes: package should generally be co-maintained by sponsor and non-DD
maintainer, with the non-DD maintainer doing most of the work
Unreferenced footnotes: [2], [3]
[2] http://lists.debian.org/debian-vote/2007/06/msg00145.html
[3] http://lists.debian.org/debian-project/2007/03/msg00103.html
== Upstream Maintainers ======
Another possible use for the DM process is to allow the upstream author
of a package to contribute more directly to that package's development
within Debian. Many hackers are Debian users, and have a fair idea of how
Debian works, without the full understanding we expect of DDs. Allowing
them to co-maintain their own software with an existing DD maintainer
would allow the upstream author to become more familiar with Debian by
hacking on the parts of the package they're most familiar with, while
relying on the DD co-maintainer for advice and handling of more Debian
specific issues.
Authorised by: Existing maintainer
Notes: package should be co-maintained by maintainer and upstream, upstream
generally to be expected to be uploading code changes rather than
packaging changes
Unreference footnotes: [4]
[4] http://lists.debian.org/debian-vote/2007/06/msg00153.html
== Principled Resignations ===
Occassionally developers have resigned from the project not because they
are unable or unwilling to keep contributing, but because they feel the
project has taken such a severe misstep they feel resignation is the
only way too show their level of disagreement, or the only way they can
distance themselves from that choice sufficiently. For individuals in that
position, who nevertheless do wish to keep contributing to Debian without
being an member of the project, being a DM provides a way of doing so.
Authorised by: Continuing DD
Notes: voluntarily resigned from DD, so having a subset of permissions raises
no issues
[5] http://lists.debian.org/debian-project/2007/05/msg00253.html
== Probationary DDs ==========
In some cases, applicants in the n-m process have a history of poor
behaviour that they wish to put behind them -- this may involve trolling
or flaming on lists, or computer system cracking, or otherwise. In
cases like this, it's often difficult to balance the desire to not given
people who are known to cause problems access, with the desire to allow
people who've made mistakes in the past to learn from them and contribute
productively in the future. Adding the possibility of being a DM to the
existing possibilities of being a DD or nothing at all gives us a way
to provide "limited trust" to people who we hope and believe will be
useful contributors, but nevertheless have historical reasons to mistrust.
Authorised by: DAM/FD
Notes: this largely serves as an alternative to delaying or rejecting
applications, and perhaps occasionally an alternative to accepting
applications that DAM/FD are uncomfortable with
== N-M Delays ================
A common complaint about n-m are a number of procedural delays: notably
(1) in progressing from having an advocate to being assigned an AM; (2)
delays due to the AM not sending new mails for the applicant to respond
to and/or finalising the report; (3) delays in DAM approving the report;
(4) delays in keyring-maint adding the key to the keyring.
For applicants who have contributed signficantly to free software projects
already and have already demonstrated a good understanding of Debian,
DM would make it possible to give a limited earlier approval to decrease
the impact of delays (1) and (2); and in cases where the delays in (2)
or (3) become extended, FD or DAM could respectively use the limited
priveleges of granting DM membership to minimise the impact of delays
outside of their control.
Authorised by: advocate, AM
Notes: only when applicant is very experienced and has a good track record
of working with others
Authorsied by: FD, DAM
Notes: applicant is already procedurally close to being accepted as DD
==============================
Anyway, those are some of the ways I think DM status could be used within
Debian. It might or might not be exhaustive -- I hope it's not. I think
it makes more sense to leave it open so DDs can use it in interesting and
sensible ways themselves, rather than trying to specify it up front --
at least as long as we have some basic policies on how to use it and
can definitely stop it from being a problem if it turns out to be.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature