> On Thu, 5 Sep 2002 [EMAIL PROTECTED] wrote: > > > Date: Thu, 5 Sep 2002 13:10:51 -0400 > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
