Hey all,

As a slight distraction from other discussions going on, I'd like to
throw a couple of ideas out there for consideration, particularly with
debconf coming up and a chance for many of us to discuss things in person.

First, the "Debian Maintainers" concept, ie giving limited upload access
to people prior to, or instead of, them becoming developers. For this
to be useful, the process should be lightweight, but still provide a
good means of ensuring we (and our users) can maintain our trust in the
packages that get uploaded.

I think the process should involve:

- automated application process

- as close as feasible to automated keyring maintenance

- policies developed by consensus and implemented individually by
developers, in a similar manner to policies for sponsored
uploads at present, rather than an individual or group setting
policy or approving applications (like DAM or NEW processing)

MJ Ray phonecoop.coop> writes:

I'm intrigued. Considering that Debian Project is a non-legal,
multinational entity, which courts would have what jurisdiction over
which actions? I don't think I would stand a chance on having a
Finnish court do a damn thing about any action made by the project.

--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *

Anthony Towns azure.humbug.org.au> wrote:

I support this idea. One question: how to remove bad or MIA DMs?

I'm less sure of this one. Haven't past self-nominations been
rejected partly because the current team should *want* help for it to
work effectively?

Specific problems: why three as the limit? What is core and what
isn't? How can competence be demonstrated for tasks which require
privileged access to infrastructure?

This has much merit, apart from the "absolutely final" bit. Allow one
appeal route (an undo GR?) within the project and realise that if we
go barking mad, there is *always* a possibility of Real-Life courts.

On Thu, May 31, 2007 at 06:37:53PM +1000, Anthony Towns wrote:

[..]

[..]

[..]

I love the DM idea.

[Resent to d-project by Cord Beermann debian.org>]

On Thu, May 31, 2007 at 06:37:53PM +1000, Anthony Towns wrote:

Well, this may work to a point, but in every justice, there is a phase
of presentation of evidence, of verification of that evidence, and a
phase where an amical resolution can be found.

I propose that a we create a debian-mediation private (same as
debian-private) mailing list, where those interested in mediations can
participate. This will also resolve the problem of issues going to other
random list and disturbing the traffic there.

Every social problem should be taken only to this list, and if someone
is seen as starting some elsewhere, he is gently remainded to go to
debian-mediation, and if he doesn't comply, the list-master take some
action (like a temporary ban, or a partial ban on a given thread, or a
plain redirection, including maybe a retroactive of moving the mail
archive to debian-mediation, or some incremental variation thereof).

On Thu, May 31, 2007 at 06:37:53PM +1000, Anthony Towns wrote:

This shouldn't be tricky.
Some webpage where the applicant applies and then they point some developers
at a page so that they can recommend/advocate him to be a DM. Very similar
to nm.debian.org advocate bits.

e.g. https://nm.debian.org/nmadvocate.php?email=hgjghj%%40hotmail.com
(which I presume is a fake application for NM but still)

The applicant would provide their keyid, email, name etc.

I think technically this is easy but we need to define who can advocate and
how much contact with the potential DM is needed (see below).

jetring exists and was pretty much designed with this in mind so this should
be easy.

The format for the changesets so far seems to be:

I don't like it at first read, but you may provide examples of
situations where such a procedure could be useful. In particular, just
determining "who's right" doesn't help much. As for determining what
punishments are plausible, isn't this better done by a committee
specialized in the Constitution?

Anthony Towns writes ("Two GR concepts for dicussion"):

This sounds like a good idea to me.

One thing that would be really helpful would be an ability for a
Maintainer of this kind to make updates without review iff it can be
shown to be safe. (Where `safe' means `the Maintainer gets to screw
over people who run this program, but not anyone who doesn't.)

I'm not sure exactly what the criteria would be but basically you'd
diff the previous and new packages and allow only certain kinds of
changes (eg, changes to existing programs in /usr/bin would be fine).

Ian.

On 18:37 Thu 31 May , Anthony Towns wrote:

Hi Anthony,

I think the use of an existing fields "Maintainer" should do the job but Im not
in favour of "Uploaders". Im throught the NM process and member of the parted
team so Im in the uploaders field. If I will have this kind of right, I could be
able to upload a new version of parted and maybe then broke the d-i for exemple.

So for the "Maintainer" field, ok, but for "uploader" we should maybe need to
take care about what are the packages co-maintained and if they are 'critical'.
We could maybe check the "Section" field and only allow some of them for a DM.

friendly,
--
,''`. Xavier Oswald
: :' : GNU/LINUX Debian & Debian-Edu
`. `' GnuPG Key ID 0x88BBB51E
`- 938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E

On Thu, May 31, 2007 at 06:37:53PM +1000, Anthony Towns wrote:

s/can (have problems)/will at some point $1/

It should be noted that DPL intervention hasn't really been a solution so
far, only a option that nobody ever utilized. That's TTBOMK - someone
correct me if I'm wrong.