[M3devel] M3 concerns

[hendrik at topoi.pooq.com]

On Sat, Jan 05, 2008 at 01:04:47AM +0000, Jay wrote:
> 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.

Distributed revision systems have completely implicit, low red-tape 
branching just by being distributed.
 
> 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.

gravityboy (http://gravityboy.livejournal.com/39755.html) has a few 
things to say about people who compare svn with cvs:  essentially, he 
says cvs is so obsolete no one should even be comparing things with it 
any more.  Saying something is better than CVS is like saying that 
a new model of automatic washing machines work better than rocks by the 
side of the river.

> 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