RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<rwi...@at...>]

> Rob,
> 
> > Do we know that we can restrict access to the main 
trunk to the
> > maintainers, then issue expanded rights to select 
individuals to their
> > branches?  The original model we had discussed was 
that the main trunk
> > was the most volitile, and both experimental work 
and stable releases
> > (and it's patches) are managed as branches.
> > 
> > What are the user access controls available to us 
from SF?
> 
> None as far as I know. If you have developer status 
you have commit
> rights anywhere (I think they've never anticipated 
that kind of strict
> distinction that we're discussing here - perhaps it 
might be worthwhile
> to send them a note explaining why we think along 
these lines).
> 
> BTW, I've been thinking about the issue of (either 
accidentally or
> non-accidentally) making "mistakes" but (in hindsight) 
I really don't
> think this is going to be a problem. For one thing, we 
_all_ make
> mistakes at times (just remember this fundamentally 
flawed ClassBuilder
> CS recently), CVS can deal with many of the problems 
in a reasonably
> straightforward way, and I also don't think the VM 
developer community
> would tolerate any non-agreeable behavior that would 
put the stability
> of Squeak on _any_ platform at risk. The last line of 
defense is having
> project admin status which (as far as I am aware) all 
of the primary
> maintainers have. 

Andreas, Hurray!  That sounds very reasonable and 
balanced between stability/reliability and openness.  We 
can take advantage of all the volunteers, yet ensure a 
level of quality and hopefully minimize flux/thrash.  

I messed up this process this morning, in fact.  The 
problem wasn't that I committed to the main branch, 
because *nix wasn't compilable with VMMaker32-7.5 and we 
are still at the pre-integration stage wrt Ian's code.  
The problem was that I didn't inform Lex and this dist 
list that I was doing the work.  

> 
> It still bothers me that I _could_ make modifications 
to (say) the unix
> tree but it appears that this can't be helped. Perhaps 
a good line in
> the policy document would be to state that you "Never, 
NEVER do a 'cvs
> commit' from the platforms directory but only from 
your platform branch
> (win32, unix, Mac, Acorn, Cross)". I've been using 
this policy for me
> already and so far it turns out to be a good practical 
rule.

Heh.  This is what I did this morning for the changes, 
but I had to re-checkout the toplevel to add 
osExports.c.  Of course, I had done a 'cvs diff squeak', 
first, to verify that I was only commiting the files I 
had planned on commiting.

Are the aliases I had defined in the CVSROOT/modules 
file a good idea?  It may be better to checkout the 
explicit subtrees (Cross and unix in my case).

Cheers,
Rob

PS.  I am posting through the web for the first time, 
since I am at work.  I may be too busy later, to post 
immediately.