Re: The Debian Maintainers GR

[Russ Allbery <rra@debian.org>]

Raphael Hertzog <hertzog@debian.org> writes:
> On Sun, 29 Jul 2007, Russ Allbery wrote:

>> So propose something that implements it, rather than implementing
>> something different and then saying we can change it later.  It's
>> always easier to change things before they start.

> This is not true in general in the free software world, and the GR
> process is even less suited to create a better proposal by having
> severals rounds of discussion (due to the delays it induces).

> Don't let the perfect be the ennemy of the good.

I think one of the places where we're disagreeing is that I don't consider
the current process fundamentally broken.  I went through it.  I thought
it was fine.  Admittedly, Marc went out of his way with me to not follow
simple templates and instead let me do work during NM, which I greatly
appreciate, but he did that within the existing system and if that's the
direction we want to go, we could do that within the existing system with
some effort.

Yes, the DAM wait is very long.  However, I think it results in good
decisions, and I just have a hard time getting that upset about the long
wait.  It's perhaps not the best weeding factor, but it's frankly not a
bad one.  Lots of churn on the developers of open source projects can be
very frustrating and even destructive to the positive energy of the
project.  I'm not saying we should force people to wait, but honestly
there are worse things that we could do than require people demonstrate
some long-term committment to the idea of becoming a DD.

So, basically, I consider the current system good.  Not ideal, not
something that couldn't stand to be improved, but good.  And I don't want
to see an unnecessary escalated confrontation (which apparently this is
much more than it appeared) or any sort of "NM is broken, we must do
something, this is something, therefore we must do this" proposal.

The problems with the current system, in my opinion, are mostly exposed in
sponsoring, where sponsored packages are frequently the bastard
step-children of the project and where the level of quality is widely
varying and the process sometimes quite frustrating.  I think the idea of
letting someone upload packages before getting full DD rights is very
sound and can be used to address some of those problems.

(Ideally, in my opinion, there would be little or no sponsorship as there
is today and instead there would be detailed review of one's packages
leading to DM status for those packages as part of an NM process, with the
other cases where that isn't appropriate done as team maintenance with the
non-DD as part of a team.  But that's an aside, and it may be that idea
wouldn't hold water on further examination.)

> May I remind you that we're all volunteers and if you come up with such
> a GR, most likely none of those people will feel concerned about
> implementing it?

Joerg already mostly wrote up the sort of thing I'd like to see.  I should
probably not be spending time writing GRs rather than doing work, but I'd
be happy to see someone turn that into a GR.  I probably shouldn't be
spending time discussing GRs rather than doing work.  :)  (It's very hard
to back out once I've put my oar in.)

> You need to have buy-in from ftpmasters too and here we have at least
> one ftpmaster ready to work on the required infrastructure. Say him "no"
> and you'll have trouble finding another ftpmaster to do something
> similar.

I doubt this, honestly.  For one thing, I doubt that AJ, as much as that
may be tempting, would actually hold a grudge that way for very long; he
doesn't seem like that kind of person to me.  For another, there are other
ftpmasters, and there are people willing to do a lot of the coding.  I
expect we could work it out, although it may require more patience than
people want to have.

> Why do you trust DAM/FD to do the right thing more than the people
> listed in the current GR ?

Well, I discussed that largely above.  I think they're doing a good job
now.

However, I'd like to point out that the people listed in the GR *are* the
same people as the DAM/FD except that the GR adds AJ, Joey Hess, and Ryan
Murray.  Ryan Murray is in the "already way overloaded category already"
and AJ has already said that he doesn't want to do package review and
seems to be more interested in doing the infrastructure work.

So what it seems like you're proposing is that the world would be much
better if Joey Hess could approve DMs.  Did I miss something?

I have a ton of respect for Joey, and if he wants to take that on, I'm
sure he'd do a great job.  But, y'know, if the goal is to get Joey into
the loop and able to make changes, I really think there are other ways
that we could do that.

Maybe what I missed was some intention that the DM keyring maintainers be
a rubber stamp on the advocacy process and not do any additional checks?
If that's really the intent, then I don't think this GR is good at all; I
think it's actively a bad idea.  That's simply not the level of check that
I'd like to see done when giving someone upload rights to Debian.  (And
yes, I know that sponsors don't check well enough either; that's also a
problem, and compounding it and making it more official doesn't help.  At
least with sponsors they have to check again each time and there's some
hope that they'll catch any problems with quality; some sponsors are very
good about that.)

Also, on another front, adding AJ, Joey, and Ryan Murray to a team isn't
exactly helping with getting new people involved who might have more free
time.  How many other hats do those three people already wear?

It really feels to me like, even if everything you say is true and the
details of how things are run aren't that important and the important part
is to set up another system and break through a logjam, this proposal
doesn't even do *that*.  It puts the usual suspects on the spot once again
for doing the usual tasks, which is something that we're quite good at
doing with the existing system.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>