[M3devel] M3 concerns

[hendrik at topoi.pooq.com]

On Sat, Jan 05, 2008 at 02:32:35PM +0100, Olaf Wagner wrote:
> Discussions seem to loose their focus quiet easy on this list :-/
> 
> I'd strongly prefer if we could keep the discussion of alternative
> version control systems out of this. It won't help us, and you can
> trust this opinion as I really know many version control systems
> (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce,
> AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite
> adequate for the simple purposes and requirements we have. Changing
> will make things different, but not better, and cost a lot of efforts
> we should rather invest into other topics.

I quite agree.

But if you have this experience,  it would be useful to see a rundown 
of the advantages and disadvantages of each.  I've seen a table of 
features against version control systems, but it doesn't give any feel 
for what it's like to use them.

Such an essay would be useful for those involved in other projects.  It 
probably won't help Modula 3 itself.

Or might you know of such an essay elsewhere?

-- hendrik

> 
> I'd like to get back to the original topic. How do we need to improve
> the CM3 development process to ensure and increase the overall quality
> of the CM3 code base? Could everybody interested in this discussion
> please just comment on the following items to state his opinion:
> 
>  o I think we have agreed on the fact that automatic regression testing
>    would help and should be introduced. Tests should be run daily/nightly
>    on as many platforms as possible, and results should be collected
>    and made available via WWW (elego offers to host these services, as
>    it does for CVS repositories and CM3 web access).
> 
>    Technical details should be discussed in a different thread.
> 
>  o Do we need / want to restrict the commit access for the CM3
>    code repositories?

At the very least, you should keep spammers out.

> 
>    If so, only for certain areas, or for everything? This would
>    be a distinction based on packages.
> 
>    Should we allow or prefer committing new code to branches and
>    merge the resulting change sets based on reviews? (I could also
>    contribute automatic support for creating change sets on branches,
>    as this is part of the DCVS functionality elego developed some time
>    ago). This would be a distinction based on code lines.

What's the 'D' of 'DVCS'?
 
>    Yesterday I had the impression that some members of this list
>    would prefer some access restriction, but I'm not really sure.

The real questions are whether corrupt code is checked in often enough 
to cause trouble to other developers, whether check-in conflicts 
happen enough to be troublesome, and whether the red tape of lots of 
branches would be more trouble than it is worth.  I don't know the 
answer to this.

For preparing regular stable releases, it is probably worthwhile to 
freeze development on a release branch, but to keep fixing bugs on both 
the development and the release branches.

As for reviews of changes, that should happen whether there's an access 
restriction or not.  It may be the most important role of those who are 
knowledgeable with the code base.  And they should probably happen 
before debugging.

-- hendrik