[MITgcm-devel] MITgcm_contrib

[Ed Hill]

On Mon, 2003-08-04 at 21:41, Chris Hill wrote:
> Ed,
> 
>  The attached web article talks about how to manage access to different
> strands within a CVS tree.
> 
> Chris
> 
> On Mon, 4 Aug 2003, Chris Hill wrote:
> 
> > Ed (and others),
> > 
> >  How do we want to handle permissions on /u/gcmpack/MITgcm_contrib? This
> > is going to be a fairly open area that people who have contributed
> > setups can put things. Seems like it should have a different group to
> > gcmpack to avoid accidental damage to core MITgcm/ mitgcm.org/ manual/
> > etc... Any suggestions/thoughts? Note - we will still have to add a name
> > to CVSROOT/writers to allow write access to an account. Or we could
> > create a second CVSROOT area?
> > 
> >  We have groups "ecco", "gcmpack" and "mitgcm" at the moment. I know
> > what "gcmpack" is I think. I'm not so clear on when and how "migcm" and
> > "ecco" ar being used?


Hi Chris,

Good article.

Heres some thoughts: allowing a lot of people CVS write access is not
good because it gives them a chance to mangle things.  So with pserver,
careful use of groups, and/or multiple CVS trees you try to setup
finer-grained permissions to make it harder for folks to mangle things. 
Ok, thats one approach.

But what if you solved the problem a different way?  What if you tried
to use peer review instead of permissions?  If newer developers had to
run their patches through more experienced folks then they would (in
this hypothetical world) [1] get some quality feedback that'd help them
learn and [2] the experienced folks would act as a filter keeping out
the junk and preventing mangling.  Peer review is good, right?

So you can do the all above by allowing just a select few to do CVS
checkins and having all the untrusted folks sending in patches using the
good old Unix "diff" and "patch" commands.  But these command-line tools
are cumbersome and not easy to teach to new developers.  And all the
patch-handling is a pain for the "core" group.  What if you wrote some
nice graphical tools that made a "diff and patch" approach a lot easier
and more intuitive, both for the new users and the main developers?

At that point, you've had just re-implemented BitKeeper.  ;-)

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Room 54-1424;  77 Massachusetts Ave.
            Cambridge, MA 02139-4307
email:   eh3 at mit.edu,  ed at eh3.com
URL:     http://web.mit.edu/eh3/
phone:   617-253-0098
fax:     617-253-4464
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20030805/6de9f0ae/attachment.sig>