- 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








-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to