[M3devel] M3 concerns

[hendrik at topoi.pooq.com]

On Sat, Jan 05, 2008 at 01:13:35AM +0100, Olaf Wagner wrote:
> 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?

The philosophy among the monotone developers (who use monotone as their 
revision control system) is to separate committing from certification. 
Anyone can commit a revision, which cen then be looked at, discussed, 
revised a few times, and if found worthy, certified.  It gives them an 
informal kind of flexibility for small changes.

Because monotone is a distributed revision conttrol system, they 
frequently have multiple heads in a branch (I prefer to call them 
leaves, or buds ready for the growth of new twigs).  It's usualy to 
check out the most recent certified revision when you start a new 
bit of development.  But being stuck with multiple heads, and 
having their system understand multiple heads, gives them a kind of 
flexibility that reflects the chaotic structure of real-sorld 
development.

Official branches can also exist.  If so, it's usually done by 
certifying revisions with different branch certificates.  Botice that 
one same revision of one same file can be on several branches with no 
problems at all.

I fact, it's perfectly possible to discover that development that has 
gone on for a few weeks really belongs on a different branch and so 
certify it after the fact.

Now I'm not telling you to convert your whole development system to 
monotone, though I might advise it if you were looking for a new 
revision-control system.  Such a changeover could involve substantial 
disruption.  But looking at how it's done there might suggest 
possibilities after you map it hack to what you are using.  The 
separation of commit from certify seems to be quite useful.

-- hendrik