[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
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
- More locking, sort of, cvs, 2002/09/05
- Re: More locking, sort of, Noel Yap, 2002/09/05
- Re: More locking, sort of, Kaz Kylheku, 2002/09/05
- Re: More locking, sort of,
david <=
- Re: More locking, sort of, Greg A. Woods, 2002/09/05
- Re: More locking, sort of, Matthew Hannigan, 2002/09/06
- Re: More locking, sort of, Greg A. Woods, 2002/09/06
- CVS vs Aegis (Re: More locking, sort of), Matthew Hannigan, 2002/09/07
- Re: CVS vs Aegis (Re: More locking, sort of), Greg A. Woods, 2002/09/07
- Re: CVS vs Aegis (Re: More locking, sort of), Matthew Hannigan, 2002/09/08