Re: The Debian Maintainers GR
Reinhard Tartler <email@example.com> writes:
> Russ Allbery <firstname.lastname@example.org> writes:
>> For example, if a DM wants to later become a full DD, so far as I can
>> tell they get no automatic credit for being a DM. While an AM could
>> take that into account, it shouldn't have to rely on an AM to evaluate
>> that. It should be a natural next step that can be taken by people who
>> want to.
> This isn't prohibited or prevented by the current proposal. Moreover, it
> explicitly lists the FD and DAM members as people who can implement what
> you are proposing here.
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.
>> I'm happy to have people not get general upload access until they have
>> passed checks on their ability to deal with NMUs, shared libraries, or
>> other things that they don't care about for their own packages, but I
>> think *everyone* with upload permission needs to go through P&P (not
>> just the stripped down version in this proposal) and understand that
>> they're making a committment to the project as a whole, not just to
>> some individual packages.
> This is a question of policy, and TBH, I'd expect FD/DAM to implement a
> policy like this, which is against supported by the current proposal.
No, it's not. The current proposal explicitly states something different
as the starting policy. Again, if you agree with me that this is the
wrong policy, change it *now*, don't pass something that's wrong and say
that we'll just change it later.
> Furthermore, I haven't seen one proposal in this thread which wouldn't
> be implementable by the current proposal. Hey, it can even by
> voided/disabled by keyring-maint or DAM by simply refusing every person
> to go through the DM process. Furthermore, DAM/FD/keyring-maint is able
> to make every further restriction or precondition they can think of.
You seem to believe this is a feature, but to me, this is a serious bug.
If we're voting for the proposal on the basis that all it creates is a
governance structure and everything else will be at the discretion of the
people involved, the proposal should *say* that rather than laying out a
bunch of initial policy. It instead lays out a lot of detailed procedure
which contradicts many of the proposals mentioned on this thread and does
not imply that's all going to change drastically as soon as the proposal
I can see voting for something that says "we empower the DAM and FD to
create a new class of Debian Developers who don't have general upload
rights, and leave all the details to them." I can see voting for a more
detailed proposal that's different than this one. But I'm not going to
vote for a detailed proposal that differs from what I want to see plus a
"trust us, we'll fix it all by changing all those policies" statement.
> The top complaints I'm reading from this thread are:
> 1. it has been proposed by AJ
> 2. it is too detailed (the micromanagment argument)
Neither of those are my complaint. In fact, I was strongly predisposed in
favor of this in part because it was proposed by AJ, and in fact voted in
favor of it initially before changing my vote after thinking about it some
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>