[M3devel] M3 concerns

[Tony Hosking]

On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote:

> I've seen quite a number of m3commit and m3devel messages lately.   
> Many of these give the appearance of "thinking out loud" with  
> various commits followed by apparent reversals.  In many cases the  
> m3commit log messages are terse and don't give the rationale behind  
> the change.

Yes, I agree.  Also, I tend to avoid committing multiple small  
patches and rather defer until I have had a chance to test everything  
and let it stabilize, before checking in as one single commit.   So,  
less frequent, coherent commits, are preferable to many smaller,  
incoherent commits.

>  For those of us in the M3 community who rely upon the stability of  
> the libraries and core M3 principles, these types of messages cause  
> concern.  While I appreciate everyone's efforts to move forward, I  
> don't want to abandon the great care that went into formulating  
> this language.

Indeed.

>  Question:  As various people make contributions and changes, is  
> there any group of folks who is verifying that the changes don't  
> break existing code or core principles?  Another idea would be to  
> have a series of test batteries that have to be passed before  
> changes can be accepted.  I know of a number of projects where many  
> people contribute, but the contributions have to be vetted by  
> passing some tests.

I try to verify that all my code doesn't break existing code (though  
I admit GC/thread subsystems can be devilish to completely verify).   
We do need to have some sort of procedures in place for deciding what  
commits make sense and should go into the CVS head.  Tentative work  
should always be done to a CVS branch until it can be vetted.

>  Without these types of controls, I fear that good forward progress  
> will inevitably be hampered or compromised by changes made by  
> someone who hasn't completely thought out and tested the  
> ramifications of those changes.

Agree!

>  For example, I've tried to get cm3 working for me on Windows XP  
> several times.  I still can't seem to get the "current" system to  
> build correctly on XP.  In the past, I have on occasion gotten the  
> "system" to build, but then some of my programs don't work  
> correctly when rebuilt using the new cm3.  Thus, some changes  
> somewhere have "broken" my code, yet all of my code uses the "safe"  
> subset of the language.  If I go back to my old reliable cm3  
> version 4.1 (the last one put out before Critical Mass, Inc. threw  
> in the towel), my code compiles and works, even on Windows XP, even  
> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g.,  
> pickles shared between Windows & Unix boxes), etc.!  Much of my  
> code was originally developed under Windows NT, so I think it is a  
> tribute to the original language developers that my code and their  
> compiler work through various OS version upgrades (NT, 2000, XP)  
> and changes to the underlying C/C++ compilers used to build the  
> core components.

I thought we were getting closer to stability in this regard, though  
I am not a heavy Windows user and have never built CM3 on Windows.

>  I would appreciate constructive feedback on this topic.

It would be great to have a set of regression tests run on a regular  
basis to ensure that checkins don't break things.  What good  
candidates do we have?  cm3 itself I suppose.  Any others?  I can  
probably devise a couple of thread and GC stress tests pretty  
easily.  Anyone willing to set up a testing regime? I have machines  
that could be used to test on several supported platforms on a  
nightly basis even.

>
> Regards,
> Randy Coleburn
>
>
> Randy C. Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, & Electronics  
> Division (CNE)
> Corporate & Atlanta Information Systems Security Manager (ISSM)
> Scientific Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770)  
> 989-9497
>
> Quality Policy:  "SRC CNE Division is committed to delivering  
> continually improving research & engineering excellence that meets  
> or exceeds customer requirements."