<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I oppose most red tape.<BR>
<BR>
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.<BR>
<BR>
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.<BR><BR>
Perforce I am quite familiar with.<BR>
Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.<BR>
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.<BR>
<BR>
This is a small project.<BR>
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.<BR>
<BR>
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).<BR>
<BR>
The system does build itself, the compiler and "std" packages. I consider that a pretty good start.<BR>
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.<BR>
<BR>
I'll look what Olaf commited over the weekend..<BR>
<BR>
Bah humbug and happy new year, :)<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sat, 5 Jan 2008 01:13:35 +0100<BR>> From: wagner@elegosoft.com<BR>> To: hosking@cs.purdue.edu; m3devel@elegosoft.com<BR>> CC: m3-support@elegosoft.com<BR>> Subject: Re: [M3devel] M3 concerns<BR>> <BR>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR>> <BR>> > My comments embedded:<BR>> ><BR>> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:<BR>> <BR>> >> Ah well, Windows is a somewhat special topic. I even haven't a system<BR>> >> here for tests, and most of the other contributors don't use it either.<BR>> >> I was of the opinion that Jay Krell had fixes or workarounds for most<BR>> >> current problems (except for the missing LONGINT support), but I haven't<BR>> >> tried his distribution archives yet. It would indeed be very helpful<BR>> >> if we could setup regression tests on Windows, too.<BR>> ><BR>> > LONGINT = INTEGER on Windows, which is fine as far as it goes<BR>> > (everything builds appropriately), but not particularly useful.<BR>> <BR>> I know that it should run this way, but pickles for example wouldn't<BR>> be exchangeable then, would they? Has anybody tested pickle support<BR>> for LONGINT yet?<BR>> <BR>> >> It would also be possible to define a group of reviewers for every<BR>> >> change, but I doubt that there would be enough competent volunteers,<BR>> >> and I'm afraid that it would rather repress development of CM3.<BR>> >> And we really need to have development, as the underlying systems and<BR>> >> techniques change and we need to adapt to that. So I'd vote for<BR>> >> free commits for everybody, as long as there are not too many<BR>> >> contributors, and setup of continually improved regression testing.<BR>> >> And we don't need to worry, as all changes can be reverted; we won't<BR>> >> lose development history with CVS.<BR>> ><BR>> > One option is to have moderated commits for non-core developers. After<BR>> > someone has earned the trust of the core developers they can be elected<BR>> > as a member of the core team. This approach is used with the Jikes RVM<BR>> > (www.jikesrvm.org).<BR>> <BR>> I wouldn't object to such a policy, though I don't really think that<BR>> it is currently necessary. But if more active committers do prefer<BR>> it, we can set up the necessary commit checks. I assume that Randy Coleburn<BR>> and you are in favour of restricted commits? What about the others?<BR>> <BR>> Who would volunteer to review commits from other people? Would this<BR>> be a responsibility inherited by the unrestricted access?<BR>> <BR>> Should we allow commits to branches and only restrict access to the<BR>> main line?<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><br /><hr />Share life as it happens with the new Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008' target='_new'>Start sharing!</a></body>
</html>