[Xorg] New committer process?

[Keith Whitwell]

Egbert Eich wrote:
> Keith Packard writes:
>  > 
>  > Around 11 o'clock on Jun 14, Egbert Eich wrote:
>  > 
>  > > I've tried to take into account discussions we had previously on this and
>  > > other lists. Please note that this is only a draft and should serve as an
>  > > RFC. I'm not aware of any comments so far.
>  > 
>  > Let's have a few comments then.
>  > 
>  > Given that CVS is completely insecure (anyone with write access can damage
>  > or destroy the repository), I suggest that we need some minimal process for
>  > granting write access.
> 
> Yes, for the way we handle things this is definitely true.
> However This would only apply of someone either screws up on purpose
> or is crazy enough to do things that he has no clue about. (You can
> only destroy the repository when you access the files directly.)
> Frequent backups of the repository would help to lessen the danger
> of loosing things in this event.
> 
>  > 
>  > I don't know what form this should take though; the proposal for 
>  > 'sponsorship' has a lot of benefits, but does tend to shut out people who 
>  > are new on the scene.  We might also consider granting access in some kind 
> 
> I don't understand this. Not giving CVS write access immediately does
> not shut out people.
> Requiring some minimal proof of the sincerity of the request and the
> quality of work before letting people write to CVS does not seem to
> be unreasonable to me. 
> I would expect that anybody who is interested in providing new code
> would check out the tree, hack away, come up with an initial implementation,
> make it public (mailinglist, bugzilla) and then - if his code seems reasonably
> sane - he gets CVS commit access.

This is pretty much how it has worked in the DRI & Mesa tree, and we've been 
pretty happy with it.  The only time anyone has done anything 'questionable', 
they cleared it up themselves shortly afterwards.

I definitely think that CVS write permission should be distinct from direct 
ssh access to the repository.  I don't see any reason for non-admins to have 
that level of access.

One thing I miss from sourceforge is a formalized procedure for adding and 
removing developers - by formalized I guess I mean that there was a web page 
and you did stuff through that rather than a vague process of emailing people. 
    Just being able to pull up a list of who did & did not have committer 
access was helpful.

Keith