<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Tony:</DIV>
<DIV> </DIV>
<DIV>I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them.</DIV>
<DIV> </DIV>
<DIV>For an example of how all this works, take a look at the scoreboard set up for the ACE+TAO+CIAO projects. An overview is at <A href="http://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scoreboard/</A> . They provide instructions for setting up your own daily build and scoreboard at <A href="https://svn.dre.vanderbilt.edu/viewvc/autobuild/trunk/README?revision=HEAD">https://svn.dre.vanderbilt.edu/viewvc/autobuild/trunk/README?revision=HEAD</A> . You can see the scoreboard in operation at <A href="http://remedy.nl/">http://remedy.nl/</A> .</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy</DIV>
<DIV><BR>>>> Tony Hosking <hosking@cs.purdue.edu> 1/2/2008 1:36 PM >>><BR><BR>On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote:<BR><BR>> I've seen quite a number of m3commit and m3devel messages lately. <BR>> Many of these give the appearance of "thinking out loud" with <BR>> various commits followed by apparent reversals. In many cases the <BR>> m3commit log messages are terse and don't give the rationale behind <BR>> the change.<BR><BR>Yes, I agree. Also, I tend to avoid committing multiple small <BR>patches and rather defer until I have had a chance to test everything <BR>and let it stabilize, before checking in as one single commit. So, <BR>less frequent, coherent commits, are preferable to many smaller, <BR>incoherent commits.<BR><BR>> For those of us in the M3 community who rely upon the stability of <BR>> the libraries and core M3 principles, these types of messages cause <BR>> concern. While I appreciate everyone's efforts to move forward, I <BR>> don't want to abandon the great care that went into formulating <BR>> this language.<BR><BR>Indeed.<BR><BR>> Question: As various people make contributions and changes, is <BR>> there any group of folks who is verifying that the changes don't <BR>> break existing code or core principles? Another idea would be to <BR>> have a series of test batteries that have to be passed before <BR>> changes can be accepted. I know of a number of projects where many <BR>> people contribute, but the contributions have to be vetted by <BR>> passing some tests.<BR><BR>I try to verify that all my code doesn't break existing code (though <BR>I admit GC/thread subsystems can be devilish to completely verify). <BR>We do need to have some sort of procedures in place for deciding what <BR>commits make sense and should go into the CVS head. Tentative work <BR>should always be done to a CVS branch until it can be vetted.<BR><BR>> Without these types of controls, I fear that good forward progress <BR>> will inevitably be hampered or compromised by changes made by <BR>> someone who hasn't completely thought out and tested the <BR>> ramifications of those changes.<BR><BR>Agree!<BR><BR>> For example, I've tried to get cm3 working for me on Windows XP <BR>> several times. I still can't seem to get the "current" system to <BR>> build correctly on XP. In the past, I have on occasion gotten the <BR>> "system" to build, but then some of my programs don't work <BR>> correctly when rebuilt using the new cm3. Thus, some changes <BR>> somewhere have "broken" my code, yet all of my code uses the "safe" <BR>> subset of the language. If I go back to my old reliable cm3 <BR>> version 4.1 (the last one put out before Critical Mass, Inc. threw <BR>> in the towel), my code compiles and works, even on Windows XP, even <BR>> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., <BR>> pickles shared between Windows & Unix boxes), etc.! Much of my <BR>> code was originally developed under Windows NT, so I think it is a <BR>> tribute to the original language developers that my code and their <BR>> compiler work through various OS version upgrades (NT, 2000, XP) <BR>> and changes to the underlying C/C++ compilers used to build the <BR>> core components.<BR><BR>I thought we were getting closer to stability in this regard, though <BR>I am not a heavy Windows user and have never built CM3 on Windows.<BR><BR>> I would appreciate constructive feedback on this topic.<BR><BR>It would be great to have a set of regression tests run on a regular <BR>basis to ensure that checkins don't break things. What good <BR>candidates do we have? cm3 itself I suppose. Any others? I can <BR>probably devise a couple of thread and GC stress tests pretty <BR>easily. Anyone willing to set up a testing regime? I have machines <BR>that could be used to test on several supported platforms on a <BR>nightly basis even.<BR><BR>><BR>> Regards,<BR>> Randy Coleburn<BR>><BR>><BR>> Randy C. Coleburn, CISSP<BR>> Senior Systems Engineer, Communications, Networks, & Electronics <BR>> Division (CNE)<BR>> Corporate & Atlanta Information Systems Security Manager (ISSM)<BR>> Scientific Research Corporation<BR>> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339<BR>> voice: (770) 989-9464, email: RColeburn@SciRes.com, fax: (770) <BR>> 989-9497<BR>><BR>> Quality Policy: "SRC CNE Division is committed to delivering <BR>> continually improving research & engineering excellence that meets <BR>> or exceeds customer requirements."<BR><BR><BR></DIV></BODY></HTML>