Re: [Sablevm-developer] suggestion: sablevm developer doc

[Chris P. <chr...@ma...>]

Prof. Etienne M. Gagnon wrote:

>On Tue, Mar 18, 2003 at 11:27:19AM -0500, Chris Pickett wrote:
>  
>
>>I agree, CVS only allows for a few different models.  However, other 
>>than the problem of creating a branch every time you want to release, I 
>>can't really see what's wrong with having short-lived branches.
>>    
>>
>
>How much development experience do you have on moderately big software
>projects?  [I seriously want a detailed answer to this question.  You
>may answer privately, if you think it is more appropriate.]
>  
>
Not that much at all, save for 6 months in Japan where I set up a CVS 
repository / project management system for 100 students, and contributed 
to the E-Cell project (large-ish simulation project written in 
C++/python/domain-specific modelling language).  I am not a programmer, 
the largest thing I have written is probably my WIG compiler in 520 at 
McGill (5000 lines of Java using SableCC, of which I wrote 80%).  I 
didn't do my undergraduate degree in CS (it was biochemistry) and I only 
started really programming in C a couple of weeks ago.  I know Java a 
lot more than I know C (obviously) and am somewhat familiar with design 
patterns.  Hell, I don't even have Linux installed on my laptop (my only 
machine) and I do everything using ssh/tty and emacs.  All in all, I sux0rz.

>
>Personally, I do see all kind of problems with short-lived branches
>(specially for managing an automatically generated changelog file,
>which is necessary to honor the requirements of the LGPL license, in
>case you were not aware).
>
Okay, I did not know that.  I have not read the LGPL license, I just 
know broadly what it entails.  I'll read it.

>
>I don't have time to justify every single little decision of mine.
>You will have to learn to live with some of my decisions, or you may
>fork your own project.  One of these decisions is that will live with
>a single trunk, no branches.
>  
>
Hey, it's okay.  I'm not pushing you for branches.  It's a real pain, 
and I understand that.  I'm essentially maintaining a branch in my local 
repository anyway.

>The only thing I can do, if you want to put all sort of stuff into
>CVS, is to start a "distinct module", sablevm-experimental, that could
>live in parallel, where there would be, again, a single trunk, but
>where all developers can check-in stuff freely (as long as the code is
>licensed appropriately, no non-clean-room contribution as usual).
>  
>
> In fact, it would have 2 brances: Trunk & Vendor branch.  The latter
> would track changes in the sablevm module.

> What do you, and others, think of this?

I think that's fine, but what potential problems do you see w.r.t. synchronization?  If someone fixes something in the experimental branch, do they submit a patch for it to be included in the non-experimental branch?

I have no problem being restricted to not committing anything to the main development  module unless explicitly asked.

Maybe you want to send an email to the info-cvs list I gave a link to, explaining the current problems and the specifics of our project (# of developers, CVS version, code size, etc.), and see what they have to say about your solution.

>>Can we have write access in the meantime then? 
>>    
>>
>
>Most other developers already have write access.  You won't get write
>access before:
>1- You change your SF user account name to something more professional.
>  
>
I already did that ... immediately after you asked me ... it's cpickett 
now (look at the comment I just made in the bug tracker).  you can even 
close those bugs and re-open them if you don't want ihatemcgill to show 
up in the bug tracker.

>2- You ask me for it, and we make the mandatory agreement on legal issues.
>  
>
Ok, I'm asking you.  I can sign whatever you want me to sign.  As for a 
clean room, I can guarantee that much for sure.

>[Personally, I was toying with the idea of moving to a "old" Linus
>model where contributions would be submitted as patches (but using a
>SF tracker, in stead of the mailing-list), just to make sure no hot
>headed developer went and screwed up the CVS repository
>inadvertently...]
>
>  
>
>>are only a handful of developers.  We could set up a cvs-commit mailer 
>>that automatically sends out all changes and who made them.
>>    
>>
>
>You have to learn to RTFM (or I should say RTFWP [Web Page])...  Have
>you looked at the links at the top left of the www.sablevm.org web
>page?
>  
>
sorry, I didn't know there was one.  i read so many WP's all the time i 
forget where things are.  my bad.  there are so many M's for me to FR 
right now.

>>I don't *desperately* need write access.
>>    
>>
>
>Go say that to Linus Torvalds.   Ha ha! :-)))))
>  
>
Okay, I don't need write access at all.  It would just make things a bit 
easier for me.

>Seriously, SableVM users expect me to make sure write access is given
>carefully, so that the legal status and the technical stability of the
>project are not jeopardized.  So, first I need to know that whatever
>you will check-in won't cause problems.  There's nothing wrong with
>setting your own private PRCS repository, which is what I do!  PRCS is
>fantastic for managing local CVS snapshots.  Try it.  It doesn't
>create CVS subdirectories, so it doesn't conflict with CVS. :-))
>  
>
Okay, I can do that.  Or maybe I'll switch to using Subversion (since it 
sounds like you want to try it in the future)

Basically, there are two reasons why I would like the 
sablevm-experimental module:

1) So I can more easily synchronize my changes with other people's 
changes while still keeping them under version control.  The project I 
am working on is speculative multithreading, and should be fairly 
independent of other SableVM stuff, and will probably not really break 
anything except itself.
 
2) So I can contribute documentation to the source code, as well as to 
separate documentation files.  This is more for the benefit of other 
developers of course ... if I spend the time to document / understand a 
file, chances are I don't need to read those comments so much -- but it 
should help others.

Cheers,
Chris

P.S.  I hate debates like this too.  I hope we don't ending hating each 
*other* :-(  Not good for collaboration . . .