Re: Proposal - Project infrastructure team procedures
- To: email@example.com
- Subject: Re: Proposal - Project infrastructure team procedures
- From: Manoj Srivastava <firstname.lastname@example.org>
- Date: Wed, 30 Apr 2008 23:54:13 -0500
- Message-id: <[🔎] email@example.com>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <20080430232750.GB19150@orion.carnet.hr> (Josip Rodin's message of "Thu, 1 May 2008 01:27:50 +0200")
- References: <20080417193441.GA3676@pork.homeip.net> <20080419182425.GB17366@xanadu.blop.info> <20080429225359.GA3386@orion.carnet.hr> <20080430105529.GA17044@xanadu.blop.info> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20080430232750.GB19150@orion.carnet.hr>
On Thu, 1 May 2008 01:27:50 +0200, Josip Rodin <firstname.lastname@example.org> said:
> On Wed, Apr 30, 2008 at 05:27:56PM -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?
>> Are people who were grandfathered by the constitution (or some such
>> equally silly argument) not also grandfathered by this forthcoming
>> GR? What changes?
> That's a good question, and the reason why I initially proposed that
> we don't try to force the delegation/undelegation system as it is - it
> doesn't seem entirely appropriate for the teams because some things
> simply predate the notion of a project leader, it will easily seem
> anachronistic and pretentious for the leaders to be able to undelegate
> someone's access to something they've created and maintained for a
> decade, without requiring any sort of a criterion to base that
> decision on.
> But others don't seem to mind that...
Err, no one has an absolute right to project resources, even if
they have maintained the resource for the project for a decade. And no,
I don't think a lot of people have a problem with that. I certainly do
These are not individual resources, they are _project_
resources. Access to project resources is governed by the
constitution, and is delegated to individuals for a certain period. The
resource ownership remains with the project, and it can, by mechanisms
detailed in the constitution, take the delegated pwoers away. No matter
how long the delegation has lasted.
The lack of major upheaval in reaction to the recent delegations
certainly point to the fact that all the fear, uncertainty and and
doubt people had about what would happen if you added people to core
teams were somewhat overblown.
Real programmers can write assembly code in any language. :-) Larry
Wall in <8571@jpl-devvax.JPL.NASA.GOV>
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C