Date: Sat, 4 Mar 2000 18:09:04 +0000 From: Josef Karthauser <joe@pavilion.net> To: Nate Williams <nate@yogotech.com> Cc: Peter Wemm <peter@netplex.com.au>, Mark Murray <markm@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/crypto/openssh login.c sshd.c Message-ID: <20000304180904.N34231@florence.pavilion.net> In-Reply-To: <200003041720.KAA09488@nomad.yogotech.com> References: <joe@pavilion.net> <20000304154049.C402D1CE0@overcee.netplex.com.au> <20000304155633.J34231@florence.pavilion.net> <200003041720.KAA09488@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 04, 2000 at 10:20:53AM -0700, Nate Williams wrote: > > > > I'm working on changes to the CVSROOT perl scripts to make this easier. > > I propose that we extend the 'avail' file syntax to add the names of the > > hosts that it's ok to commit a particular part of the tree to. > > I think making such a special case so flexible is *way* too much > overkill. Most (99.99%) of CVS projects are hosted on a single site, > and our multiple site setup is not common. As a matter of opinion, I > suspect this is the only one in existence, so trying to make CVS files > to support this isn't worth the effort, because it's functionality only > FreeBSD would use, and messing with the avail code (that many other CVS > repositories use) would potentially make the existing code unusable to > others. You've missed the point of what I'm saying. The code in CVSROOT is _very_ FreeBSD specific already in as much as it has hostnames and usernames and repository paths and mailing list names hard coded within the perl code. If this can be moved out into a configuration file that makes the code more generic and of wider appeal. If these configuration files also allow us to do extra things, even if no-one else other than us uses them, then why not? As it happens I've got a requirement for a multiple site setup that mirrors the way that FreeBSD works already. I'm part of a group of seven or eight companies. Each has their own systems department, and we all share code. We all have our own repositories but want a shared structure so that we can all have a unified copy of the repository locally with read/write access to our bits, and read only access to every other bit. > > This will also enable me to remove a lot of the hard coded cruft from > > the perl scripts. > > The only hardcoded cruft is in commit_prep.pl, and it's either > hard-coded in one-place there or hard-coded in avail. Either way it's > hard-coded. Yes, but one place is code, and the other is a configuration file. > > In addition I would also like to include the email address that > > gets mailed with the commit message to this file. > > This I could see as a good thing, however it would be *much* more > maintenance on the part of folks who use avail (instead of access) for > do ACL's. > > The existing format is: > > avail|users|repository > > The implication being that 'users' are the people who are allowed commit > access. If you add 'mailing address' as well, then do we send email to > the users, or to the mailing address, or what? At the moment the question of where mail goes is decided within log_accum.pl. If we want create a new mailing list this script needs to be hacked. A list is selected on the basis of a repository location, and avail is a list of repository locations. Assuming that we agree that the mailing lists should be in a config file, not in code, they could easily be tacked onto avail file and it's syntax expanded to allow for default addresses, etc. > It's trivial to add another entry for the mailing list to the 'users' > list right now, and if you want security then add an entry to 'passwd' > with an '*' entry, so no-one can ever get access. Yes, but this is per user, not per repository location. > As you can imagine, I have lots of ideas (and a bit of experience here, > having done this sort of thing for 5+ years at commercial sites), and > would rather not see FreeBSD's CVS scripts become even more FreeBSD > centric, with no gain in functionality, but additional flexibility that > benefits no one. I agree - my goal is to make the system more generic so that others can pick it up and use it, but also to make it more powerful. Joe -- Josef Karthauser FreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000304180904.N34231>