Reinhard Tartler <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> 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 is adopted. 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 more. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
