Re: Re: [XFree86] Invitation for public discussion about the future of X

Keith Whitwell <[email protected]>
Newsgroups gmane.comp.xfree86.forum
Message-ID <3E7A5E27.8050606__36454.763756092$1048344527@tungstengraphics.com>
>>
>>
>>>	- Extend CVS access to regular contributors.  Use scripts or 
>>>	whatever to control access to subtrees if you want.
>>
>>This comes up from time to time, and I'm sure will get discussed even more.
>>I know there have been offers to others for CVS commit access, and some
>>have refused and some have accepted. The consensus of who gets commit
>>access has always been - if they show competance at sending patches in,
>>then after a period of time, no doubt they'll get it. It's the same as
>>the DRI, but with more of a prolonged period of evaluating that persons
>>patches. I guess this 'prolonged' period, is the stickling point for most.
> 
> 
> 
>     Keith, I'm sure you've seen some pretty shady patches come your
> way so you understand that review by qualified people is essential.
> I believe we do need more commiters, particularly in some parts of
> the tree, but I also believe that this commit access should be
> granted only to people with sufficient expertise, not merely to
> people who have a vested interest.  I know we have poor coverage
> in some parts of the tree, and I think that needs to be fixed.

Yes, but it's also important to grant people responsibility that may challenge 
them.  Many will rise to it.

And, you could use scripts to keep people to their assigned areas -- a 
particular driver, for instance.  Though I think people will respond better to 
being trusted than being subjected to rigid restrictions.

I guess this is the big issue from another side:  XFree86 doesn't seem to 
trust anyone - there's a lot of fear & concern about what might possibly in 
the worst  circumstances go wrong as a result of allowing someone cvs access. 
    My experience is people respond to being trusted and will go out of their 
way to try and live up to that trust.

> 
> 
>>>	- Consider dropping the BOD and core team ideas in favour of an 
>>>	elected committee.  Examine recent trends in managing other large projects.
>>
> 
>  Just some somewhat disconnected statements:
> 
>     I think that elected commiters is a bad idea.

I agree.  This idea probably arose from my confusion between the concepts of 
'advisory board', 'core team', and 'committers'.

>     I have a low opinion of the usefulness of advisory boards.

Sure.  But I would argue an elected one is better than the current approach.

>     I have a strong respect for competent developers.  I suppose
> that make me an elitist, but no more that you are, I suppose.

We all love 'em.

>     I think one of our main problems is that we've linked CVS commit
> access with the "5 year plaque", and I think we should emulate
> Linux kernel's development model more closely instead.

This is pretty much on target.  If nothing else changes, expanding the commit 
rights to 2x or 3x the number of people currently with that access would be a 
signal that xfree was learning from this debacle.  I recognize that a lot of 
progress to openness has occurred, but there remains only a very small number 
of people who can commit code to what is a very large source base.  One result 
is that you end up with things like the dri tree, another result is that 
competent developers just decide they can make a bigger impact elsewhere & go 
away.

It would be interesting to understand how the linux kernel methodology would 
apply here.  I think there are a lot of special circumstances that keeps that 
magnificant house of cards standing - I'm not sure I'd want to bet on being 
able to reconstruct that network of trust relationships from scratch.

But it's fun to think about...  Would the whole core team be Linus, or would 
they give up commit access and funnel everything to David?  ... or should we 
just use the original Linus for this too? :->   OK, maybe not.

Keith
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.