[M3devel] M3 concerns

[Olaf Wagner]

Quoting Randy Coleburn <rcoleburn at scires.com>:

> 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.
>
> 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.

I agree that some of the recent commit messages seem to give the
impression of quick changes. More care should be taken here.
I'm not really concerned about the stability of the whole system,
as those changes did mostly concern build infrastructure and minor
fixes and adaptions.

> 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.

Automated regression tests have been on my agenda for CM3 for a long
time. I coulnd't contribute much myself during the last year, as I've
been very busy. I've done a little bit in the last two weeks, and
others have also worked in this area, so that I hope we will be able
to present some working regression test setup within some days. At
least we'll have some initial setup that can be extended and improved.
More to this topic in another mail.

> 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.

Yes, this is the usual problem with all systems without periodic
automatic regression testing.

> 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.

Ah well, Windows is a somewhat special topic. I even haven't a system
here for tests, and most of the other contributors don't use it either.
I was of the opinion that Jay Krell had fixes or workarounds for most
current problems (except for the missing LONGINT support), but I haven't
tried his distribution archives yet. It would indeed be very helpful
if we could setup regression tests on Windows, too.

As for the stability and interoperability, this is a very complex
requirement that needs much care and testing. It is difficult to achieve
in an open source project, at least in one with so few contributors.
I'm sure Critical Mass did an excellent job on this, but it's been
a commercial company with other organization and resources. We'll
have to become better in this respect step by step.

It would also be possible to define a group of reviewers for every
change, but I doubt that there would be enough competent volunteers,
and I'm afraid that it would rather repress development of CM3.
And we really need to have development, as the underlying systems and
techniques change and we need to adapt to that. So I'd vote for
free commits for everybody, as long as there are not too many
contributors, and setup of continually improved regression testing.
And we don't need to worry, as all changes can be reverted; we won't
lose development history with CVS.

> I would appreciate constructive feedback on this topic.
I hope this has been constructive enough,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194