[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The Debian Maintainers GR

On Sun, Jul 29, 2007 at 01:17:23PM +0200, Luk Claes wrote:
> Why not, he didn't ask for any reaction from FD, NM or DAM before proposing,
> so I very much blame him for not having a good proposal in the vote...

Okay, I've been avoiding this issue, but the above's an outright lie,
and since DAM and FD seem to be encouraging that misapprehension,
I guess I can't avoid addressing it anymore.

As people are presumably aware, I first proposed this back in April
last year on my blog. This was then taken up by Marc 'HE' Brockschmidt
(one of the front desk members) as part of his "Reforming the NM Process"

] 2.3 Separate upload permissions, system accounts and voting rights
] ------------------------------------------------------------------
] This one is a long-time goal. There's a discussion about this at the
] moment anyway, but the problem is known for a long time. By splitting
] these three things apart, we gain a lot of flexibility and could solve
] things like sponsoring on the way. This is mainly based on a proposal
] Anthony Towns made to me in private.

    -- http://lists.debian.org/debian-devel-announce/2006/04/msg00006.html

Christoph Berg (another of the front desk members) ran a BOF on the topic
at debconf 6 in Mexico, "The Future of the NM Process" primarily about
introducing Debian Maintainers as a new step in n-m. He posted some of
the ideas to -newmaint first:

] 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.

    -- http://lists.debian.org/debian-newmaint/2006/05/msg00015.html

And a video of the session is available at the meeting-archives page:


After that meeting [0], I'd assumed it was in Christoph and Marc's capable
hands, and had moved onto other things, but it didn't progress, and during
January there was a flare up on -private about how much things suck --
developers can find the threads in the archive on master by looking for
threads beginning with timestamps of "Date: Tue, 23 Jan 2007 14:04:08"
and "Date: Wed, 24 Jan 2007 10:15:48". The former ended with:

] The current DAM and buildd team have shown often
] enough that they don't care about the fact that other people believe
] that they are doing a bad job.

Those threads resulted in my mail to -project trying to disentangle the
situation with those roles so we could get some progress:


Behind the scenes I'd tried talking to James and Joerg to get some specific
actions to improve things, beyond just clarifying who has what roles. In a mail
to James and Joerg, cc'ed to leader@debian.org, I proposed:

]     (1) Clear the current backlog in account creation. This one's up
]         to James.
]     (2) Clear the current backlog in application rejections. This one's up
]         to Joerg, with James reviewing.
]     (3) Encourage AMs and FD to ensure applications are at a level
]         where they can personally advocate the applicant; if they're
]         not at that level, allow the applicant to contribute in reduced
]         ways instead, but remove them from the n-m process. This one's
]         up to FrontDesk.
]     (4) Help keyring-maint become more maintainable, by: (1) developing
]         some automatic tools for maintaining the keyring by signed emails;
]         (2) writing docs to help developers understand how to manage
]         their keys and reduce work for keyring-maint; (3) add some
]         frontline support for keyring-maint to weed out spam and make
]         sure requests are in a form that they can be acted upon. This
]         one's for Steve and me to get our cadre of anonymous volunteers
]         to work on, with James reviewing.
]     (5) Get the debian-maintainers thing (non-developers able to do
]         direct uploads of packages they're listed as Maintainer: of,
]         having passed the initial n-m checks, but not the in-depth P&P/T&S
]         ones) operational in limited form. I'm hoping Christoph will
]         help me get this one done initially, and that the keyring-maint
]         improvements will make it work long term.

James didn't quote the last point in his reply, simply saying:

] I don't have a particular problem with the rest of the email.

after commenting on some other bits. Joerg's response to the last point was:

] Thats something I am thinking about for some longer time already. Its
] not all that easy, IMO.

Joerg and James both corrected a misapprehension I'd had at that point,
which was that Joerg had been passing on hard cases (where AM reports
required further review or dealing with expulsion) to James; so I
followed up at that point endorsing Joerg as full DAM [1], which had
been in question.

Some of Joerg's comments elicted some heated rebuttal/corrections from
James ("God DAMN it, I hate this meme so fucking much!"), and Joerg's
reply disagreed on the merit of a bunch of points particularly the
frontdesk review point, so I didn't try proposing the above points any
more broadly (I'd been hoping to send them to FD at a minimum).

Some of them have had some progress including a bunch of accounts created
during the DPL election, but, some didn't, such as Peter Samuelson's DAM
processing, which I'd explicitly referred to as an example that should
have been trivial for the DAMs to process, as any problems should have
been resolved at AM stage since it was AMed by a FrontDesk member. Peter's
still in the DAM queue at the time of writing.

That conversation was between the 10th and 20th of February, with the post
to -project coming on the 23rd of February. Again on the 23rd I posted
James' mail about improving keyring-maint that he'd sent to leader@
while Branden was DPL [a], and by fairly late on the 23rd Joey had got
a first prototype of jetring started [b].

    [a] http://lists.debian.org/debian-project/2007/02/msg00226.html
    [b] http://lists.debian.org/debian-project/2007/02/msg00242.html

At about the same time as contacting James and Joerg, I pinged Christoph
about his continuing interest [2] since he'd run the Debconf BOF. The
reasons I didn't ping Marc (who'd posted to d-d-a) should be apparent
from the timing.

On the 25th I mailed Joey and Christoph privately to see what their thoughts

] So what do you both think of using these scripts to start maintaining a
] "Debian Maintainers" keyring, as per [0] or Myon's talk at dc6? I figure:
]    (1) setup a debian-maintainers.gpg keyring and package using jetring
]    (2) populate it using (some of) the people currently waiting for
]        DAM approval, based on FD's recommendation (ie, Myon's).
]    (3) add a list mapping "maintainer name" and fingerprint, so we don't
]        have to rely on key uids for determining whether a key is
]        authorised to upload a package maintained by "John Doe".
]    (4) roll out support in dak
] ?
] The currently waiting folks seem a pretty easy beta pool, and after that
] point we can see about extending it to people who haven't already passed
] the full AM/FD checks.

Christoph replied on the 26th, Cc'ing FD and DAM with:

] a tool to manage gpg keyrings (and specifically debian-keyring.gpg)
] would be very nice to have. From what James said earlier anything that
] avoids the "blob problem" is an improvement for DAM/keyring-maint.

] First of all, I think we shouldn't unilatterly jump ahead and give
] more people access to the archive before there's some consensus about
] that among DAM, front-desk and the project in general.

] Some months ago, the (perceived) problems with NM were that it a)
] takes to long to get an AM b) NM takes too long and c) DAM/FD approval
] takes to long. We managed to cut down a) by raising the entry level a
] bit (which also helps b) since better NMs yield more motivated AMs).
] c) has been taken care of by having a second DAM, only the account
] creation still takes longer than non-involved people would expect.
] The keyring tool might help there.
] Now, letting the people in the DAM queue upload wouldn't change much.
] In theory, DAM approval would be more or less instantly, in practise
] it happends after a few weeks. Adding more infrastructure for the few
] uploads NMs would do during that time sounds like overkill.

] Generally changing the rules and letting people upload earlier would
] need a modified NM process with some stripped-down version of the
] current one. That would make a difference, but in practise those
] people motivated enough to become DD will complete the current process
] in a few weeks, and those less interested in "immediate upload rights"
] will probably still take a long time in completing the new "light"
] process. I don't think we can do without any formal/written checks, so
] we wouldn't gain much.

Joerg responded to Christoph's message about four hours later, saying: 

] >> So what do you both think of using these scripts to start maintaining a
] >> "Debian Maintainers" keyring, as per [0] or Myon's talk at dc6? I figure:
] > First of all, I think we shouldn't unilatterly jump ahead and give
] > more people access to the archive before there's some consensus about
] > that among DAM, front-desk and the project in general.
] Yes, and doing it without DAM would get me to take the keyring that this
] builds up as a blacklist.
] While I agree that we *may need* to discuss ways in making it easier to
] contribute to Debian, which includes easier ways to upload, having
] something like this done right away now is the wrong way. And can only
] count as "Lets try to get some "nice" PR, DPL votes coming up".
] Instead of doing half-thought implementations which don't help we should
] come up with something that may change the whole DD status, splitting it
] in multiple sets of rights. Like "Can vote", "Can upload own packages",
] "can upload $whatever", "has access to machines". Where those levels are
] ordered (not really like what I wrote here)  and each level means "you
] got the ones before this plus these additional steps".
] Just, it isn't that easy to do this right. Sure, people that only want
] to maintain their one and only package and dont need an address is a
] simple case, but everything else is more problematic:
]  - when do we give out @debian.org addresses? If you maintain one, two,
]    ten packages? What about all the sponsors that invest a whole lot of
]    money into Debian for machines, bandwith, etc?
]  - when do we give out voting rights? Why does someone who maintains,
]    lets say two, packages get voting rights, but not the sponsor who
]    gives us unlimited bandwith for years?
]  - when does one get machine access?
] Also, what do you plan to check for such maintainers? Nothing? Social
] Contract/DFSG "uphold" only? More of P&P? What I can read it shows that
] this is a "Schnellschuss" and nothing good now.
] >>    (1) setup a debian-maintainers.gpg keyring and package using jetring
] >>    (2) populate it using (some of) the people currently waiting for
] >>        DAM approval, based on FD's recommendation (ie, Myon's).
] You seem to always forget that FD has two members. Why?
] > Now, letting the people in the DAM queue upload wouldn't change much.
] > In theory, DAM approval would be more or less instantly, in practise
] > it happends after a few weeks. Adding more infrastructure for the few
] > uploads NMs would do during that time sounds like overkill.
] Currently it happens after a few months. :() Mid/end of december and
] still waiting. Thats a more important thing to solve than this
] "debian-maintainer keyring".
] I am pondering the "modify NM and the DD status" thing for a long time
] now. Haven't got it to a point that I like and already deleted multiple
] starting .txts, so nothing send out to anyone. (It sure needs to get
] discussed by DAMs first, then FrontDesk, then project). I plan to have
] something more until DebConf7 latest, to discuss stuff and see how/if
] one can go on. Probably earlier by mail already. But as this touches
] something central it will take time.

I don't know if Christoph actually asked if I'd mind if he cc'ed DAM
and FD; I can't see any evidence of it in my logs, but I imagine I'd
have said "sure" anyway. In any event I was pretty offended by Joerg's
threat to blacklist any new contributors who went through the DM thing
and his accusation that it was all a DPL campaign stunt, and that's
pretty much the last time I sought his opinion. My response was:

] > Yes, and doing it without DAM would get me to take the keyring that this
] > builds up as a blacklist.
] Joerg, if you decide to abuse your position as DAM in protest of someone
] else trying to improve Debian, that's your business, just as it has been
] when you've done it in the past by refusing to process NEW. I'm sorry
] that you aren't able to cope better when you don't have complete control
] of everything, but this sort of response isn't the way to promote your
] point of view, or encourage anyone to consult you in the first place.
] > While I agree that we *may need* to discuss ways in making it easier to
] > contribute to Debian, which includes easier ways to upload, having
] > something like this done right away now is the wrong way. And can only
] > count as "Lets try to get some "nice" PR, DPL votes coming up".
] Yes, clearly, that's the only *possible* reason for doing it now. It
] couldn't possibly be anything to do with the tools just becoming
] available. Grow up.
] >  - when do we give out @debian.org addresses?
] >  - when do we give out voting rights?
] When you're a developer.
] >  - when does one get machine access?
] When the admin of the machine gives you access.
] > >>    (1) setup a debian-maintainers.gpg keyring and package using jetring
] > >>    (2) populate it using (some of) the people currently waiting for
] > >>        DAM approval, based on FD's recommendation (ie, Myon's).
] > You seem to always forget that FD has two members. Why?
] Mostly because FD is listed as having three members on the website. Myon's
] active and interested, and when I spoke with HE yesterday he indicated
] he didn't have time.

Neither Joerg nor Christoph responded further, and James and HE didn't add
their two cents to that thread at all. At that point I did some hacking
on dak to see what was actually possible, and a couple of weeks later (on
the 15th of March) posted the "Developers vs Uploaders" mail to -project.


James, Joerg, Christoph and Marc didn't participate in that thread at

This coincided with the expulsion procedure for Sven Luther, however,
which Joerg had reactivated on the 7th of February, and which was posted
to -private on the 1st of March, and continued until the 28th of March
at which point Joerg posted that the DAMs had decided upon a one year
suspension, and then beyond. In particular the deadline for mailing
comments to DAM on the matter was 14th of March.

In any event, James poked me on IRC on the 15th, presumably after seeing the
thread on -project, saying:

    <elmo> umm, aj, dak is not looking at a keyring not managed by keyring-maint
    <elmo> please do not change it to do that without talking to me about it
    <aj> elmo: ack. it's changed to look at a list of keryings, the list is
               currently the keyring-maint maintained ones

A couple of days later, on the 17th, I mailed James, Mike Beattie (as nominal,
or at least historical, co-keyring-maint), Ryan Murray (ftpmaster), and Joey

] Hey *,
] Background:
] (1) $ svn checkout svn://svn.alioth.debian.org/svn/jetring/trunk
]     $ cd trunk/example
]     $ make
]     creates debian-maintainers.gpg (and admins.gpg). It's auditable by looking
]     at the files in debian-maintainers/ and admins/
] (2) Mike mentioned at lca that he's interested in getting back into
]     Debian and possibly keyring-maint (which I see he's still technically
]     a member of); not sure if he still has time or interest, and there's
]     always that wedding thing coming up...
] (3) Email from James to leader@ (Joerg cc'ed) regarding keyring-maint:
]     [...]
] (4) Developers vs Uploaders on -project:
]        http://lists.debian.org/debian-project/2007/03/msg00074.html
] (5) From IRC:
]     [the quote above]
] So next step is to have the extra keyring looked at by dak. What level of
] keyring-maint oversight do we need/want? The ability to audit what's going
] on? The ability to remove keys asap if someone's being an idiot? I presume
] we don't want/need to have James be the only one able to add keys. Do we
] want to have everyone able to add keys be on the keyring-maint alias? Do
] we want to not have JoeyH or myself able to add keys (we're the only
] two in admins atm)?
] What considerations do we want to take into account here?

to which James' response was to mail me directly saying:

] Anthony Towns <aj@azure.humbug.org.au> writes:
] > (3) Email from James to leader@ (Joerg cc'ed) regarding keyring-maint:
] >     [...]
] Umm.  Way to quote (private) email completely the fuck out of context...
] > (5) From IRC:
] >     [...]
] And way to quote IRC messages from private channels...
] > I presume we don't want/need to have James be the only one able to
] > add keys.
] Err... so now you've gone from trying to micromanage DAM to trying to
] replace keyring-maint which isn't even a delegated position?
] Seriously what the fuck happened to you AJ?
] > So next step is to have the extra keyring looked at by dak.
] No, that's not the next step.  Just to be clear with what I said on IRC:
]  dak is not looking at a keyring not managed by keyring-maint.
] If you change this without my consent, I'll revert it and ensure you
] can't change it again through technical measures.
] You can threaten to bypass your pet DAM all you like, but you don't
] get to just bypass the other two ftp-masters in trying to railroad
] this debian-maintainers stuff through.
] #%Y"$"$#T!" I am so fucking annoyed, sorry but I can't even begin to
] reply to the rest...

I took the "I'll revert it and ensure you can't change it again through
technical measures" as a threat to drop me from ftpmaster, which shocked
me fairly severely and struck me as pretty offensive; and at that point
I took a copy of my home directories on ries and raff and made sure the
morgue was mirrored to merkel so it was accessible to non-ftpmaster DDs,
and stopped doing ftpmaster stuff for a while. I also had a few rounds
of very unfriendly argument with James, the last mail of which was an
attempt at staying technical rather than personal, but failed at least
in the sense that James didn't reply:

] So, one way or another, I find this interesting and am going to work on
] it. If that's incompatible with my being ftpmaster or having a login on
] debian.org machines or whatever, well, I would've assumed I'd already
] made it obvious I'd rather do what I think's important and fun than be
] in any particular role anyway.
] I'm afraid I don't know what your problem with it is and you haven't
] given me the impression that any changes will make it more acceptable to
] you. But since I'm all about denying reality, I'll try once more anyway.

] For the keyring, when you say "managed by keyring-maint", that is
] currently synonymous with "completely controlled by James Troup". Yes,
] I know why that is and that's not a complaint or a criticism. But if
] that's what you mean for this case, I can't see any point talking further;
] you've shown no interest in the maintainers/uploaders thing, more than
] a little opposition, and I can't see you putting in the time or effort
] to make it work, and the keyring management using a new, untested, tool
] doesn't strike me as something that can be skimped on. If I'm wrong on
] that, feel free to tell me.
] But if you mean something different than "only James Troup may touch this
] keyring", I don't know what that is, and when I tried to ask above, you
] responded with a quite explicit threat rather than any sort of answer.
] If you want to keep it under the banner of keyring-maint, I could work
] with Mike Beattie on it with the understanding that once you've had time
] to look over jetring and see what's going on, you'll take it over. Or
] something else, but not without understanding what the issue is.
] As far as any other differences from what I originally talked about goes,
] I don't think any of them are significant -- ttbomk they're all the sorts
] of things that make an initial implementation easier and less disruptive,
] without making it difficult to add in the future. If there is something
] important that needs to be in the first revision that I haven't mentioned,
] consider me all ears.
] If you aren't willing to consider me a friend, or have lost respect for
] me as a person, or whatever, that's one thing. If you're not willing to
] even respect me as a colleague and discuss technical matters such as this
] with me, though, I don't see how I can continue to act as an ftpmaster,
] whether uploaders/maintainers happens or not. If that's the case,
] please remove my membership of the debadmin, ftpteam, cvs_dak and wb-*
] groups at your earliest convenience. I've already downloaded copies of
] the contents of my home directories on raff and ries, and my crontabs
] on both machines are empty.

That was 23rd March. There wasn't a reply, and my access wasn't
removed. Early April was the release, and at that point debconf was close
enough that I don't think I bothered doing anything more until then,
at which point I stayed in the hostel one morning do up a draft which I
posted to -vote. Up until that point there had been months of time and
plenty of threads both on list and off that the DAMs or FrontDesk could
have followed up to with further comments if they'd chosen to.

After Debconf, James was kind enough to meet me for dinner in London on
the 30th June, where we had a brief (and happily friendly) discussion
about some of the DM stuff, at which point he indicated he'd try to
comment on the lists. That hasn't happened, unfortunately, though I
mailed him some URLs on the 10th of July to make reviewing the thread as
easy as possible, and pinged him on IRC on the 17th, before calling for
a vote on the 21st. I'd sent a similar mail to Christoph on the 10th,
since he hadn't participated in the thread.

So yeah, that's apparently what it means to not ask for "any reaction
from FD, NM or DAM before proposing".

As much as I'd rather pretend all the private nastiness in Debian doesn't
exist (let alone post it publicly and on the record) privately threatening
to blacklist folks as DAM while publicly claiming that it's just a lack
of discussion and work that's blocking things shouldn't be let stand IMO.


[0] Comments were mostly finding problems or issues that this isn't
    intended to address, let alone solve:

      - "What do we do about translators?"

      - "This proposal relies on their magically being more AMs who need
         to do more work"

      - "We should integrate all these non-maintainers too somehow,
         can we officially recognise non-coders"

      - "Community is a social thing not necessarily a technical one,
         creating a monoculture of technical people we run into more

      - "`Translation ownership' lets us treat translators as developers"

      - "The GenToo process involves mentors, it'd be good to have AMs
         be more like mentors" ("The AM can do whatever they want,
         even not talk to the applicant just provide points to prior
         list posts")

      - "We might have to reduce the size of Debian, because the project
         is lacking direction, and decisions could be made by fewer

      - "There are lots of discussions on -devel that end in nothing because
         no one steps forward and implements stuff"

      - "Sure it should be easier to get into Debian, but it also should
         be easier to get out of Debian"

      - "About your process: it's twelve points, which is more than 7
         plus or minus 2, which is too many. It's hard to remember all
         the points which means it's still bureaucratic, which means
         it's too complicated"

      - "If it's too easy to get upload priveleges, we might get too
         many Ubuntu MOTU people uploading into Debian, which wouldn't
         be (maybe) a bad thing, so I'm kind of scared, if we made it
         too easy to put packages in" ("It's for people who are already
         doing good work via sponsorship etc, it's just the normal way
         we've been working"; "I get requests from MOTU people who want
         to upload to Debian because it's cooler")

      - "Is there any research being done on the behaviours of uploaders,
         I guess there are very different people around -- fix bugs and
         do lots of NMUs, group maintainers, etc."

      - "What are our goals? Do we want to be a social club, or are
         we trying to produce the best distribution of Linux ever? If
         we are trying to be a social club, then yes we should lower
         the barriers of entry. Has anyone asked the release team what
         they feel about a bunch of not-very-experienced people directly

      - "People who have gone away, it's simple security, if they haven't
         uploaded packages for twelve months, that privelege should be
         removed, until they ask for it again."

      - "One solution could maybe be that packages uploaded by people
         like that stay in unstable, until they become DD or until a
         developer is willing to accept responsibility for the packages
         by being an uploader for that package" ("Then this won't
         change anything")

      - "We could implement something like this focussing first on
         technical things, then for people who want to be a DD and vote,
         we can do the extra things"

      - "If you sponsor a package in Debian, you are responsible for
         it. It's great if whoever prepared the package does stuff,
         but when you sign that upload you're saying you're personally
         responsible for the contents of that package. If you don't want
         to be responsible, don't sponsor the package. Maybe we need to
         improve the process for sponsoring so sponsors understand that."

      - "I'd say we should be both a social club and a technical group --
         look at us, we're partying."

      - "Debian keeps increasing and increasing, and there's some security
         issues with having 1000 developers with write access to the archive,
         and introducing trojans is going to be very easy."

      - "Can you give some concrete examples of checks that you think
         we need to perform for a Debian developer, but not for a
         Debian maintainer who can upload directly?" ("The whole DFSG
         stuff could be skipped, because you don't allow NEW" "But the
         contents of packages change" "How often does that happen?" "Quite
         often, adding some non-free docs, eg" "Well that would be the
         responsibility of the sponsor from the beginning" "But they can now
         upload directly, so...")

      - "Should have a role that is called Debian Community Member,
         kind of person who is not a developer, but is making rollouts,
         installation, helping people using the system."

      - "We have to make the new-maintainer process more technical, because
 	 we have to more strict about people uploading buggy packages; and we
         have to lower the barrier for people that can help a lot"

      - "To me, the answer to the earlier question is completely obvious:
         we're trying to create the best distribution. The extent
         to which people are willing to sponsor events like this and
         other things which help to improve our social interactions as
         developers are only because we understand that activities like
         these are crucial to helping people to be more productive in
         working together, not because there's any desire on anyone's
         part to provide free vacations to exotic places."

      - "We don't actually know why we want to change the new-maintainer
         process. I don't think we all agree on what people we want
         coming into Debian, and we have to decide on that before we
         can design a propre new-maintainer process"

      - "Who thinks it's a good idea? 10 people. Who thinks it's
         not? About the same. Okay, if people have more thoughts please
         talk to me, or aj. Okay, I think we have lunch now."

[1] As per:

] So, with DPL hat on, my understanding of things is that:
]    The role of DAM is to determine individuals who are or aren't
]    suitable to be Debian Developers with all the rights, priveleges
]    and responsibilities that entails.
]    Joerg Jaspert is currently lead DAM, and does the majority of the work
]    the role entails, with James Troup as backup DAM. Additional DAMs may
]    be recruited by agreement between the two existing DAMs. Otherwise
]    either member may exercise the authority of the DAM role individually,
]    but should attempt to do so in ways the other would agree with.
]    Given limitations in the way we maintain the keyring and the
]    importance of an entry in the keyring in exercising developer rights
]    such as uploading to the archive and using Debian machines, DAM can
]    only exercise its authority in cooperation with keyring-maint.
] And further I think we should add the following rule:
]     keyring-maint will review DAM's recommendations for changes to who is
]     a maintainer only in so far as ensuring the integrity of the keyring.
] Which is to say I think James should actively avoid reviewing the AM report
] once an applications been forwarded onto account creation.
] James, I understand if you're not convinced this is the right call to
] make yet -- I know you wanted to review some more of Joerg's reports
] before changing this. If we're saying DAM is a delegated position though,
] that means it's my call to make afaics, and fwiw given the above, I
] am convinced. I'm certainly completely confident Joerg's not going to
] go batshit insane, so any problems that we do have will be fixable in
] any case.
] FWIW, as far as limiting the potential impact of the above goes, I also
] think the following rule's valid:
]     DSA control who has access to machines they administer, and are
]     not required to give access to any developer to any machine. An
]     explanation as to the reasons behind access being granted/restricted
]     should be provided to the DPL if requested.
] which I think makes any risk of mistakes slipping through without more
] checks pretty fixable.

[2] As per:

--- Log opened Sat Feb 10 17:18:01 2007
<aj> ping for when you're awake; are you interested in going ahead with
     the whole "limited upload privs for non-DDs" thing we talked about
     last year? i'm inclined to give up on trying to get things so it
     can be done right, and just do it instead
--- Log opened Mon Feb 12 06:19:04 2007
<Myon> hey
<Myon> was away over the weekend
<Myon> anything on -private or else I should read up? I have ~2 weeks backlog
<aj> not in relation to the above
<Myon> from the feedback I got at DC6 and after, I'm not sure if it
       would solve any of the (supposed) problems NM or Debian as a whole have
<Myon> I'm not opposed to it, but we should know which problem we are solving 
       by implementing it
<aj> mmm? what was the feedback?
<Myon> rather the discussion
<Myon> hmm, did I write that down? let me check
<Myon> apparently I didn't
<Myon> the back-then perceived problem was "NM takes too long" along with an
       overly-long AM queue
<aj> http://lists.debian.org/debian-project/2006/05/msg00190.html was all i
<Myon> the latter has been cut down considerably
<aj> well, i'd say the particular problem is that NM is too much effort
     just to maintain a package or two
<Myon> (there's ~10 applicants waiting at the moment, unsure if that's a bad 
        sign or just a bad coincidence)
<aj> it's the people in the have-AM-not-forwarded-to-FD state that this would
     really help
<Myon> you mean this would be designed as an intermediate, temporary step?
<aj> up to 27 + 2 + 10 + 109 people
<aj> for some people it would be permanent
<aj> (who don't ever want to put that much time/effort into debian)
<Myon> we are handing out upload rights, accounts, and voting rights
<Myon> which ones do you think they should have?
<Myon> and would it imply changes for new DDs, i.e. that the default state of
       "all rights" would change?
<Myon> imho we shouldn't change the latter
<aj> limited upload rights
<Myon> and for the former only uploading sounds like a good idea
<aj> limited accounts could come later; voting rights could too, i have no opinion
     on the latter
<aj> i think it'd be reasonable for some existing DDs to switch to DM status, 
     but only if they feel like it
<Myon> yeah
<aj> (limited accounts == accounts on some boxes only, possibly only on request
      or something)
<Myon> the basic structure like in my proposal still sounds fine
<aj> (i'm downloading the dc6 video to have a look)
<Myon> *but* even uploaders of simple packages can fuck up badly, like the 
       cupsys-pdf maintainer
<Myon> so the idea of low-profile maintainers is still somehow scary
<Myon> frankly any long- or medium-term package maintainer should be able to 
       go through NM without too much effort
<aj> well one of the problems with sponsorship is if you do a broken upload, 
     and the sponsor doesn't catch it, you've got to coordinate with a sponsor 
     again to fix it; rather than just fix it yourself
<Myon> we can try to push the idea "make the AM think you are capable" more
<Myon> like I just approved peterS without T&S2 because he's just good
<Myon> the problem is that people without much involvement have a hard time
       proving that they know stuff
<aj> yeah
<Myon> e.g. it was probably futile to do NM with jcristau, had I known he'd 
       become a core member of the XSF
<Myon> I'm just browsing the NM templates, there's still between 1/2 and 2/3 
       of the questions that are relevant for single-package maintainers
<Myon> (overall, there's too many, but we are working on that)

Attachment: signature.asc
Description: Digital signature

Reply to: