[M3devel] M3 concerns

[Mika Nystrom]

I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows
2000, and, I believe, Digital Unix 4.0 systems to run nightly
(daily?) builds.  Unfortunately I am of course a bit short on Time,
which is probably what's lacking the most, anyhow...

     Mika

"Randy Coleburn" writes:
>This is a MIME message. If you are reading this text, you may want to 
>consider changing to a mail reader or gateway that understands how to 
>properly handle MIME multipart messages.
>
>--=__Part103621A2.1__=
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>Tony:
>=20
>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.
>=20
>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 http://www.dre.vanderbilt=
>.edu/Scoreboard/ .  They provide instructions for setting up your own =
>daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui=
>ld/trunk/README?revision=3DHEAD .  You can see the scoreboard in operation =
>at http://remedy.nl/ .
>=20
>Regards,
>Randy
>
>>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 1:36 PM >>>
>
>On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote:
>
>> I've seen quite a number of m3commit and m3devel messages lately.  =20
>> Many of these give the appearance of "thinking out loud" with =20
>> various commits followed by apparent reversals.  In many cases the =20
>> m3commit log messages are terse and don't give the rationale behind =20
>> the change.
>
>Yes, I agree.  Also, I tend to avoid committing multiple small =20
>patches and rather defer until I have had a chance to test everything =20
>and let it stabilize, before checking in as one single commit.   So, =20
>less frequent, coherent commits, are preferable to many smaller, =20
>incoherent commits.
>
>>  For those of us in the M3 community who rely upon the stability of =20
>> the libraries and core M3 principles, these types of messages cause =20
>> concern.  While I appreciate everyone's efforts to move forward, I =20
>> don't want to abandon the great care that went into formulating =20
>> this language.
>
>Indeed.
>
>>  Question:  As various people make contributions and changes, is =20
>> there any group of folks who is verifying that the changes don't =20
>> break existing code or core principles?  Another idea would be to =20
>> have a series of test batteries that have to be passed before =20
>> changes can be accepted.  I know of a number of projects where many =20
>> people contribute, but the contributions have to be vetted by =20
>> passing some tests.
>
>I try to verify that all my code doesn't break existing code (though =20
>I admit GC/thread subsystems can be devilish to completely verify).  =20
>We do need to have some sort of procedures in place for deciding what =20
>commits make sense and should go into the CVS head.  Tentative work =20
>should always be done to a CVS branch until it can be vetted.
>
>>  Without these types of controls, I fear that good forward progress =20
>> will inevitably be hampered or compromised by changes made by =20
>> someone who hasn't completely thought out and tested the =20
>> ramifications of those changes.
>
>Agree!
>
>>  For example, I've tried to get cm3 working for me on Windows XP =20
>> several times.  I still can't seem to get the "current" system to =20
>> build correctly on XP.  In the past, I have on occasion gotten the =20
>> "system" to build, but then some of my programs don't work =20
>> correctly when rebuilt using the new cm3.  Thus, some changes =20
>> somewhere have "broken" my code, yet all of my code uses the "safe" =20
>> subset of the language.  If I go back to my old reliable cm3 =20
>> version 4.1 (the last one put out before Critical Mass, Inc. threw =20
>> in the towel), my code compiles and works, even on Windows XP, even =20
>> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20
>> pickles shared between Windows & Unix boxes), etc.!  Much of my =20
>> code was originally developed under Windows NT, so I think it is a =20
>> tribute to the original language developers that my code and their =20
>> compiler work through various OS version upgrades (NT, 2000, XP) =20
>> and changes to the underlying C/C++ compilers used to build the =20
>> core components.
>
>I thought we were getting closer to stability in this regard, though =20
>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 =20
>basis to ensure that checkins don't break things.  What good =20
>candidates do we have?  cm3 itself I suppose.  Any others?  I can =20
>probably devise a couple of thread and GC stress tests pretty =20
>easily.  Anyone willing to set up a testing regime? I have machines =20
>that could be used to test on several supported platforms on a =20
>nightly basis even.
>
>>
>> Regards,
>> Randy Coleburn
>>
>>
>> Randy C. Coleburn, CISSP
>> Senior Systems Engineer, Communications, Networks, & Electronics =20
>> 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) =20
>> 989-9497
>>
>> Quality Policy:  "SRC CNE Division is committed to delivering =20
>> continually improving research & engineering excellence that meets =20
>> or exceeds customer requirements."
>
>
>
>--=__Part103621A2.1__=
>Content-Type: text/html; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>Content-Description: HTML
>
><HTML><HEAD>
><META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
>">
><META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>
><BODY style=3D"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=3D"ht=
>tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor=
>eboard/</A> .  They provide instructions for setting up your own =
>daily build and scoreboard at <A href=3D"https://svn.dre.vanderbilt.edu/vie=
>wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/=
>viewvc/autobuild/trunk/README?revision=3DHEAD</A> .  You can see =
>the scoreboard in operation at <A href=3D"http://remedy.nl/">http://remedy.=
>nl/</A> .</DIV>
><DIV> </DIV>
><DIV>Regards,</DIV>
><DIV>Randy</DIV>
><DIV><BR>>>> Tony Hosking <hosking at 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><B=
>R>It would be great to have a set of regression tests run on a regular&nbsp=
>; <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 at SciR=
>es.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&nbsp=
>; <BR>> or exceeds customer requirements."<BR><BR><BR></DIV></BODY></HTM=
>L>
>
>--=__Part103621A2.1__=--