On Wed, Dec 04, 2013 at 06:32:19PM -0800, Steve Langasek wrote:
> It absolutely should. The constitution stipulates that authority flows from
> the developers, through the DPL, to the delegated teams. To say that the
> DPL delegation is nothing than a rubber stamp is to say that the team does
> not recognize the constitutionally-defined power structures.
I'm not a native English speaker so I can't comment on whether "rubber
stamp" is an appropriate expression or not. But I definitely agree with
what Steve wrote here. It's very important that any "substantial extra
power" that a DD has wrt other DDs is tied to a delegation (and that, as
such, it can be publicly revoked by the DPL if needed). The DPL is the
only power in Debian that is periodically re-established via a vote
among Debian citizens; it is fundamental that disparities among DD
powers stems from him/her.
Then, of course we can debate on what is a "substantial extra power"
that need delegation and what is not. For one thing, I don't think that
commit access to a package maintenance Git repo on alioth qualifies,
especially considering that all DDs can bypass that "power" by doing
NMUs. But I'm positive we can agree on the fact that teams like DSA,
Ftp-masters, and the Release Team do have substantial more powers than
DDs who are not part of those teams [1].
So, talking strictly at the level of general principles, I don't think
that such teams should have the formal ability to self-delegate their
powers to new team members. In practice, though, we need to be very
careful of not getting in the way of working teams by imposing extra
hops on how they work or, worse, trying to inflict on them team members
they don't like to work with. It is important that we, as a project,
have the *ability* to do that via the DPL, but I don't think we should
actually *use* that ability, except in exceptional circumstances.
(FWIW, I think this characterization of things should work is compatible
with the explanation of "rubber stamp" that Ian has given in this
thread. But meh, I'm an Italian living in a French-speaking country,
what do I know about English linguistic subtleties :-))
Finally, I think implementing in practice the above principles, avoiding
awkward threads like the beginning of this one, can be easy as long as
we all adopt some simple communication best practices. Delegated teams
can try to avoid announcing new team members before giving a heads up to
the DPL; and the DPL can try to promptly acknowledge new team
memberships as soon as they get public. This way the general "rubber
stamp" principle is preserved and at the same time no DPL-team tensions
are created. (Note: I've no idea on whether this has actually happened
in this case or not. I'm only trying to address the general aspect of
how "core teams" delegations should work.)
Cheers.
[1] yes, I know, the Release Team is currently not a delegated team. I
think that is a bug that needs to be fixed, and I apologize for not
having done that.
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature