Proposals, discussions and announcements

Josip Rodin | 2 May 2008 00:24

Re: Proposal - Project infrastructure team procedures

On Wed, Apr 30, 2008 at 11:54:13PM -0500, Manoj Srivastava wrote:
> >> What bothers me about all this is that we had a nicely detaled
> >> document that spells out who has what rights, and it seems fairly
> >> clear to me that all powers in Debian stem from the powers laid down
> >> there; but that nicely detailed document is not enough.
> >> 
> >> What makes one thing that any non-supermajority GR which says
> >> essentially the same thing as the constitution will have any weight?
> 
> > The Constitution is nicely detailed, but it doesn't recognize
> > infrastructure teams. It doesn't have a generic handler (so to speak)
> > for groups of developers - it does handle delegations which can expand
> > into N developers, but this is done in a completely impractical way,
> > judging by history.
> 
>         Are teams of delegates not just multiple delegated developers,
>  who are individually covered by the constitution?

Well, if a team decides to expand on its own, which they do normally, this
is simply not covered by the constitution, at least not AFAICT - section 8
doesn't mention any such thing.

So, even if we assume here that the constitution made all team members
implicit delegates at one point, all further decisions by those original
delegates to share their work with others effectively make those other
people delegates, but they can't be replaced by the leader because a) the
leader never appointed them and b) it would be overriding a decision made by
a delegate. And the leader can't get those other people's permissions
revoked via proxy, because the proxy is the implicitly delegated sysadmin
team, whom they can't command. D'oh!

(Continue reading)

Stephen Gran | 2 May 2008 00:49

Picon

Re: Proposal - Project infrastructure team procedures

This one time, at band camp, Josip Rodin said:
> the developers never made or overrode their decision (4.1.3)

http://www.debian.org/vote/2007/vote_002
--

-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran <at> debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Josip Rodin | 2 May 2008 01:17

Re: Proposal - Project infrastructure team procedures

On Thu, May 01, 2008 at 11:49:35PM +0100, Stephen Gran wrote:
> This one time, at band camp, Josip Rodin said:
> > the developers never made or overrode their decision (4.1.3)
> 
> http://www.debian.org/vote/2007/vote_002

Oh, okay, true. That's one. Did I miss any others? :)

--

-- 
     2. That which causes joy or happiness.

Clint Adams | 2 May 2008 00:40

Picon

Re: Proposal - Project infrastructure team procedures

On Fri, May 02, 2008 at 12:24:53AM +0200, Josip Rodin wrote:
> Well, if a team decides to expand on its own, which they do normally, this

That should not happen normally.  The Constitution should not allow it
either.

Russ Allbery | 2 May 2008 01:27

Picon

Re: Proposal - Project infrastructure team procedures

Clint Adams <schizo <at> debian.org> writes:
> On Fri, May 02, 2008 at 12:24:53AM +0200, Josip Rodin wrote:

>> Well, if a team decides to expand on its own, which they do normally,
>> this

> That should not happen normally.  The Constitution should not allow it
> either.

I agree with this.  I think getting DPL blessing for additional delegates
should be simple and straightforward in the normal, uncontroversial case,
and there's no reason not to do that and several very good reasons to take
the moment required to send the e-mail and ask for it.

--

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

Andreas Barth | 2 May 2008 11:51

Re: Proposal - Project infrastructure team procedures

* Russ Allbery (rra <at> debian.org) [080502 01:27]:
> Clint Adams <schizo <at> debian.org> writes:
> > On Fri, May 02, 2008 at 12:24:53AM +0200, Josip Rodin wrote:
> 
> >> Well, if a team decides to expand on its own, which they do normally,
> >> this
> 
> > That should not happen normally.  The Constitution should not allow it
> > either.
> 
> I agree with this.  I think getting DPL blessing for additional delegates
> should be simple and straightforward in the normal, uncontroversial case,
> and there's no reason not to do that and several very good reasons to take
> the moment required to send the e-mail and ask for it.

Why not making it the other way, allowing the DPL to remove people if he
wants? So teams can expand themselfs (like the release team regularly
does), but the DPL can still make sure that no unwanted people are
delegated there.

And, reading the current constitution, we already have it that way.
Good.

Cheers,
Andi
--

-- 
  http://home.arcor.de/andreas-barth/

Josip Rodin | 3 May 2008 00:44

Re: Proposal - Project infrastructure team procedures

On Fri, May 02, 2008 at 11:51:53AM +0200, Andreas Barth wrote:
> Why not making it the other way, allowing the DPL to remove people if he
> wants? So teams can expand themselfs (like the release team regularly
> does), but the DPL can still make sure that no unwanted people are
> delegated there.
> 
> And, reading the current constitution, we already have it that way.
> Good.

I don't see it, other than the workaround I mentioned earlier in the
thread... is that what you mean?

--

-- 
     2. That which causes joy or happiness.

Manoj Srivastava | 2 May 2008 15:39

X-Face

Face

Picon

Re: Proposal - Project infrastructure team procedures

On Fri, 2 May 2008 11:51:53 +0200, Andreas Barth <aba <at> not.so.argh.org> said: 

> * Russ Allbery (rra <at> debian.org) [080502 01:27]:
>> Clint Adams <schizo <at> debian.org> writes:
>> > On Fri, May 02, 2008 at 12:24:53AM +0200, Josip Rodin wrote:
>> 
>> >> Well, if a team decides to expand on its own, which they do
>> >> normally, this
>> 
>> > That should not happen normally.  The Constitution should not allow
>> > it either.
>> 
>> I agree with this.  I think getting DPL blessing for additional
>> delegates should be simple and straightforward in the normal,
>> uncontroversial case, and there's no reason not to do that and
>> several very good reasons to take the moment required to send the
>> e-mail and ask for it.

> Why not making it the other way, allowing the DPL to remove people if
> he wants?

        Well, that does not sound like a delegation. And as all powers
 flow as powers of the DPL, delegated to other people -- I think the DPL
 ought to be actively involved in delegation.

> So teams can expand themselfs (like the release team
> regularly does), but the DPL can still make sure that no unwanted
> people are delegated there.

        Well, as I read the constitution, the added team members do not

(Continue reading)

Andreas Barth | 2 May 2008 16:22

Re: Proposal - Project infrastructure team procedures

* Manoj Srivastava (srivasta <at> debian.org) [080502 15:45]:
> On Fri, 2 May 2008 11:51:53 +0200, Andreas Barth <aba <at> not.so.argh.org> said: 
> > * Russ Allbery (rra <at> debian.org) [080502 01:27]:
> > Why not making it the other way, allowing the DPL to remove people if
> > he wants?
> 
>         Well, that does not sound like a delegation. And as all powers
>  flow as powers of the DPL, delegated to other people -- I think the DPL
>  ought to be actively involved in delegation.

I'm happy enough if the DPL can stop delegating further on. That's by
far more practical.

May I ask the question the other way round: Why stop any working team on
adding new members only because the DPL is currently too busy to approve
that new member? (Of course, if the team disagrees within itself, or
whatever, the DPL is the instance being able to make a decision.)

> > So teams can expand themselfs (like the release team
> > regularly does), but the DPL can still make sure that no unwanted
> > people are delegated there.
> 
>         Well, as I read the constitution, the added team members do not
>  really have the powers themselves, but are sub-delegates or assistants,
>  and the delegated folks have the responsibility.

So, do you think that I am Release Manager, and if so, have any power as
that, and if so, why do I have powers? (Subdelegated via aj -> vorlon ->
aba?)

(Continue reading)

Clint Adams | 18 May 2008 17:26

Picon

Re: Proposal - Project infrastructure team procedures

On Fri, May 02, 2008 at 04:22:53PM +0200, Andreas Barth wrote:
> So, do you think that I am Release Manager, and if so, have any power as
> that, and if so, why do I have powers? (Subdelegated via aj -> vorlon ->
> aba?)

I think it is because Debian is an Old Boys' Club and that the Release
Team is a fraternity.

Russ Allbery | 3 May 2008 03:17

Picon

Re: Proposal - Project infrastructure team procedures

Andreas Barth <aba <at> not.so.argh.org> writes:

> I'm happy enough if the DPL can stop delegating further on. That's by
> far more practical.

Why?  That's part of the job of the DPL.  That's sort of like saying that
you'd be happy if package maintainers could stop uploading packages, since
it would be more practical.

--

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

Manoj Srivastava | 2 May 2008 16:45

X-Face

Face

Picon

Re: Proposal - Project infrastructure team procedures

On Fri, 2 May 2008 16:22:53 +0200, Andreas Barth <aba <at> not.so.argh.org> said: 

> * Manoj Srivastava (srivasta <at> debian.org) [080502 15:45]:
>> On Fri, 2 May 2008 11:51:53 +0200, Andreas Barth
>> <aba <at> not.so.argh.org> said:
>> > * Russ Allbery (rra <at> debian.org) [080502 01:27]:
>> > Why not making it the other way, allowing the DPL to remove people
>> > if he wants?
>> 
>> Well, that does not sound like a delegation. And as all powers flow
>> as powers of the DPL, delegated to other people -- I think the DPL
>> ought to be actively involved in delegation.

> I'm happy enough if the DPL can stop delegating further on. That's by
> far more practical.

        But that is not the consitution we have agreed to. You might be
 right, the constitution is inefficient here, and perhaps blithely
 ignoring it is best, or even practical.

> May I ask the question the other way round: Why stop any working team
> on adding new members only because the DPL is currently too busy to
> approve that new member? (Of course, if the team disagrees within
> itself, or whatever, the DPL is the instance being able to make a
> decision.)

        The sub-delegation effect has precedent, and can be used as a
 stopgap until the DPL  gets time to respond.

>> > So teams can expand themselfs (like the release team regularly

(Continue reading)

Josip Rodin | 3 May 2008 01:00

Re: Proposal - Project infrastructure team procedures

On Fri, May 02, 2008 at 09:45:08AM -0500, Manoj Srivastava wrote:
>         I think you are lending credence to Clint's argument about
>  cronyism and wholescale flouting of the constitution here.  At first
>  blush, this does seem like a failure of the DPL's in question to act.
> 
>         Now, I must admit that cronyism or not, the release management
>  seems to be working, but at one point so were some of the other teams,
>  which have come under criticism of late for being obstructive.
> 
>         It boils down to this: Do we want a project governed by a
>  constitution, or do we want brilliant, hard workers, with friends in
>  the DSA (or other infrastructure teams), gain powers be mere
>  proclamation, and then present the DPL with a fait accompli that they
>  would be loth to disrupt (since it would be an improvement over status
>  quo)?

At the same time, notice that the desire of teams to be less susceptible
to random changes by the DPL stems from the need to avoid cronyism by
the DPL, which is also possible, though that one is eventually repairable.
That is also valid concern IMO, although it is not as important as fixing
the potential for cronyism and other failures in the teams themselves
which doesn't have nearly the same amount of repairability.

--

-- 
     2. That which causes joy or happiness.

Russ Allbery | 3 May 2008 03:18

Picon

Re: Proposal - Project infrastructure team procedures

Josip Rodin <joy <at> entuzijast.net> writes:

> At the same time, notice that the desire of teams to be less susceptible
> to random changes by the DPL stems from the need to avoid cronyism by
> the DPL, which is also possible, though that one is eventually
> repairable.

This really doesn't seem to be a problem that we have.  We're currently
erring so far in the other direction that I have a hard time seeing that
become the major issue.

--

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

Josip Rodin | 3 May 2008 03:28

Re: Proposal - Project infrastructure team procedures

On Fri, May 02, 2008 at 06:18:19PM -0700, Russ Allbery wrote:
> Josip Rodin <joy <at> entuzijast.net> writes:
> 
> > At the same time, notice that the desire of teams to be less susceptible
> > to random changes by the DPL stems from the need to avoid cronyism by
> > the DPL, which is also possible, though that one is eventually
> > repairable.
> 
> This really doesn't seem to be a problem that we have.  We're currently
> erring so far in the other direction that I have a hard time seeing that
> become the major issue.

I'd appreciate it if you quoted my entire paragraph, so that it was obvious
that we agree on that...

--

-- 
     2. That which causes joy or happiness.

Russ Allbery | 3 May 2008 03:44

Picon

Re: Proposal - Project infrastructure team procedures

Josip Rodin <joy <at> entuzijast.net> writes:
> On Fri, May 02, 2008 at 06:18:19PM -0700, Russ Allbery wrote:
>> Josip Rodin <joy <at> entuzijast.net> writes:

>>> At the same time, notice that the desire of teams to be less susceptible
>>> to random changes by the DPL stems from the need to avoid cronyism by
>>> the DPL, which is also possible, though that one is eventually
>>> repairable.

>> This really doesn't seem to be a problem that we have.  We're currently
>> erring so far in the other direction that I have a hard time seeing
>> that become the major issue.

> I'd appreciate it if you quoted my entire paragraph, so that it was
> obvious that we agree on that...

Sorry about that.  You did indeed say that this was less important.

--

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

Andreas Barth | 2 May 2008 23:31

Re: Proposal - Project infrastructure team procedures

* Manoj Srivastava (srivasta <at> debian.org) [080502 16:55]:
>         Now, I must admit that cronyism or not, the release management
>  seems to be working, but at one point so were some of the other teams,
>  which have come under criticism of late for being obstructive.

So, this seems to indicate that the way to add new people to the release
team isn't an issue. It however indicates also that there must be a way
how the DPL can change a team in case it isn't working anymore, and e.g.
add new people.

Which is the way it currently is. Of course, any team (including the
teams I'm part of) needs to accept if the DPL wants to change the team.
(Though I could imagine ways where I wouldn't want to stay part of the
team longer than necessary for a handover - that's something else.)

>         It boils down to this: Do we want a project governed by a
>  constitution, or do we want brilliant, hard workers, with friends in
>  the DSA (or other infrastructure teams), gain powers be mere
>  proclamation, and then present the DPL with a fait accompli that they

This sounds like a mistake to me: Why isn't it possible that the
constitution is written in a way that supports easy ways of working
together, and supports that teams improve themself, that multiple teams
together define the interface between their teams (think of what
recently happened with britney) etc? AFAIU the constitution it is
written this way, and practice seems to agree with that.

And, things don't get secretly laid out with magic ways, but people
notice who is actually doing lots of work (or just ask on d-d-a for
nominations), and from there it starts. All in the open, more or less

(Continue reading)

Josip Rodin | 3 May 2008 01:01

Re: Proposal - Project infrastructure team procedures

On Fri, May 02, 2008 at 11:31:52PM +0200, Andreas Barth wrote:
> So, this seems to indicate that the way to add new people to the release
> team isn't an issue. It however indicates also that there must be a way
> how the DPL can change a team in case it isn't working anymore, and e.g.
> add new people.
> 
> Which is the way it currently is.

Which is the way we currently *hope* that it is, but ten to fifteen years
of experience demonstrates that the model is known to fail miserably.

--

-- 
     2. That which causes joy or happiness.

Andreas Barth | 3 May 2008 10:29

Re: Proposal - Project infrastructure team procedures

* Josip Rodin (joy <at> entuzijast.net) [080503 01:09]:
> On Fri, May 02, 2008 at 11:31:52PM +0200, Andreas Barth wrote:
> > So, this seems to indicate that the way to add new people to the release
> > team isn't an issue. It however indicates also that there must be a way
> > how the DPL can change a team in case it isn't working anymore, and e.g.
> > add new people.
> > 
> > Which is the way it currently is.

> Which is the way we currently *hope* that it is, but ten to fifteen years
> of experience demonstrates that the model is known to fail miserably.

The last weeks have demonstrated reasonable well that it works in case
the DPL uses the powers he has.

Cheers,
Andi

Josip Rodin | 3 May 2008 14:57

Re: Proposal - Project infrastructure team procedures

On Sat, May 03, 2008 at 10:29:03AM +0200, Andreas Barth wrote:
> > > So, this seems to indicate that the way to add new people to the release
> > > team isn't an issue. It however indicates also that there must be a way
> > > how the DPL can change a team in case it isn't working anymore, and e.g.
> > > add new people.
> > > 
> > > Which is the way it currently is.
> 
> > Which is the way we currently *hope* that it is, but ten to fifteen years
> > of experience demonstrates that the model is known to fail miserably.
> 
> The last weeks have demonstrated reasonable well that it works in case
> the DPL uses the powers he has.

That's another rosy view, and one I've already discussed in the thread...
What guarantee do we have to think that it won't take another ten to fifteen
years of intermittant failure for the next demonstration of power? :)

--

-- 
     2. That which causes joy or happiness.

Stephen Gran | 2 May 2008 00:49

Picon

Re: Proposal - Project infrastructure team procedures

This one time, at band camp, Clint Adams said:
> On Fri, May 02, 2008 at 12:24:53AM +0200, Josip Rodin wrote:
> > Well, if a team decides to expand on its own, which they do normally, this
> 
> That should not happen normally.  The Constitution should not allow it
> either.

Don't be silly.
--

-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran <at> debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Clint Adams | 2 May 2008 00:59

Picon

Re: Proposal - Project infrastructure team procedures

On Thu, May 01, 2008 at 11:49:58PM +0100, Stephen Gran wrote:
> Don't be silly.

What's silly is pretending that there are these magical autonomous
subcultures called "infrastructure teams" that deserve sovereignty for
no apparent reason.

Return

Return to gmane.linux.debian.devel.vote.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane