[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More locking, sort of

From: david
Subject: Re: More locking, sort of
Date: Thu, 5 Sep 2002 13:03:59 -0500 (CDT)

> On Thu, 5 Sep 2002 address@hidden wrote:
> > Date: Thu, 5 Sep 2002 13:10:51 -0400
> > From: address@hidden
> > To: address@hidden
> > Subject: [info-cvs] More locking, sort of
> > 
> > Obviously, there are political problems at work here; it's not
> > feasible to beg, borrow, steal, buy, or evolve, a better breed of
> > hacker. 
Pity about that.  What you really need is people who will do a good
job, and with this job market that shouldn't be difficult (at least,
not in the US).
> Set up a Unix group which has write access to the repository.
> Ensure that everything in the repository is read-only to everyone
> else, and ensure that the directories all have the setuid bit
> so that newly created directories inherit these permissions.
There's a step missing here:  if you just do this the turkeys will
be unable to check out and update software.  You need to put a line


(change the directory as you will, but don't put any spaces in)
in CVSROOT/config, and of course have a /usr/local/cvslocks or whatever
directory that all the turkeys can write to.  Assuming a reasonably
up-to-date version of CVS, this will allow the turkeys read-only
access to the repository.
> Developers who are not in the privileged group must send patches
> to someone in that group in order to change the software.
> Set up a mailing list for that purpose.
> Initially, put only yourself into the privileged group.  Those who
> consistently send quality patches get added to the write access group.
> Those who break the software get demoted to the patch-only group.
Of course, you may already know some other people whom you would trust
with your source code.
> And of course those who don't produce acceptable patches should be
> fired. This way you have a visible process which builds solid evidence
> against the non-producers, and prevents them from being
> negative-producers.
I suspect this is not going to fly, given the political problems against
getting decent hackers.

I still have qualms about this, most particularly being that I don't
see that having competent people looking over incompetent code is
a tremendous improvement.  Perhaps instituting different processes,
such as early semi-formal reviews, would be more useful, but I know
nothing of the politics at your site.

Now building a CVS reference site at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]