[m-dev.] Remove CVS access to repository.

[Tyson Richard DOWD]

David Glen JEFFERY wrote:

> It may be worth mentioning the approximate size of the modules. If people are
> going to be accessing this from the other side of the world, they should
> probably know what they're in for.

Yep, this is a good idea. 

> 
> Also, I feel that our review procedures may need a work-over too. At the moment,
> some code still sneaks in to the repository without review (or at least without
> any recorded approval). With the inherent difficulty in communication that
> arises with developers at another site, things probably need to be a little
> tighter in order that we don't go off track.
> 

Well, it's not really the review procedures that need to be changed, but
people need to stick to them. There are pretty clear guidelines for when
something can be committed without a review, or committed before review,
which we can debate if you want, but some of the committed changes are
don't meet this criteria.

(PS set your textwidth to something less than 80).

> Here are two (somewhat overlapping) solutions:
> 
> 	* If you're at Melbourne, continue as normal. If you're elsewhere, 
> 	  then approval for a commit from someone at Melbourne must appear on
> 	  mercury-developers before you go ahead
> 
> 	* No commit is to go into the repository without some (reasonably)
> 	  formal level of approval (that even means you, Fergus :) ). Perhaps
> 	  we can have a list of people who can approve diffs (or who can 
> 	  approve other people to approve diffs...). The commitlog template
> 	  could have a field added to indicate who has approved the diff.
> 
> 	  (This is a better solution, IMHO. It may involve a little more work,
> 	  but as the group gets bigger, it is a price we probably have to pay.
> 	  We have got away with a reasonably informal process for some time
> 	  because we are a small group who work in reasonably close
> 	  communication.)

I'd go for the second option.

> While we are on the subject, are there any other process issues we need to
> look at?

A similar review process for design decisions would be good (e.g. you
propose a feature or change, outline the design it will take, get
the OK, and then go do it). Obviously this will need to iterate for
more complex designs.

-- 
       Tyson Dowd           #          Another great idea from the 
                            #            people who brought you
      trd at .cs.mu.oz.au      #               Beer Milkshakes!
http://www.cs.mu.oz.au/~trd #	         Confidence --- Red Dwarf