Re: More locking, sort of

[david]

> 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
like

LockDir=/usr/local/cvslocks

(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 http://www.thornleyware.com
address@hidden