[M3devel] M3 concerns

[Jay]

I oppose most red tape.
 
However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that.
 
I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.
Perforce I am quite familiar with.
Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.
In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist.
 
This is a small project.
I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong.
 
I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent).
 
The system does build itself, the compiler and "std" packages. I consider that a pretty good start.
I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles.
 
I'll look what Olaf commited over the weekend..
 
Bah humbug and happy new year, :)
 - Jay



> Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking <hosking at cs.purdue.edu>:> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> 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.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> 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.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > 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> 
_________________________________________________________________
Share life as it happens with the new Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080105/edf43a7d/attachment-0002.html>