Re: [Axiom-developer] [Sbcl-devel] Windows port future ... Git?

[daly]

On Mon, 2011-05-16 at 18:28 +0200, David Lichteblau wrote:
> Quoting address@hidden (address@hidden):
> > David Lichteblau wrote:
> > > Regarding git use I would like to point out that git is really cool (and
> > > I'm obviously using it), but being able to easily merge stuff between
> > > branches does not make it easy to merge the result into an upstream
> > > project.
> > >
> > > A straight "let's merge this branch" commit is not an option for the
> > > branches in question -- and would not do justice to their complexity and
> > > the amazing work Dmitry and Anton have put into them.
> >
> > I may be missing the point (and you're certainly doing a lot more than I
> > ever have) but I disagree with your statement.
> 
> It seems clear to me from Nikodemus' announcement that SBCL is being
> moved to git.  I was not actively involved with SBCL development at the
> time when git was being discussed, but I personally appreciate git's
> features and welcome this development.
> 
> Consequently, further discussion and exposition of git's virtues would
> be redundant, and I'd like to keep my response to these points as brief
> as possible.
> 
> However, every project using git has its own set of rules governing the
> appropriate steps for submitting and checking in patches, and some main
> guidelines are common to most projects.  The point I was making is
> primarily about those procedures in general, and the goals for my
> current work in particular.
> 
> > With Git, Dmitry and Anton could easily have their own "windows branch" of
> > SBCL in the official SBCL source tree.  That could happen today.  Then
> > this branch can be merged/retired as you and others refactor the important
> > pieces into the master branch (currently the only thing in CVS).
> 
> Git's advantage is that collaborative work with multiple distinct
> repositories works very well, without having highly experimental work in
> the main repository.  The existing Windows repositories are well-known
> and very visible.
> 
> > With the current setup, we have a handful of semi-official repositories,
> > people didn't even know about your work, ...  Tracking these forks and
> > merges is important.
> 
> The term "merge" has a double meaning here.  I want to _merge_ the
> windows changes, but we cannot do that through a _merge commit_ in git:
> 
> The work Dmitry and Anton have done is outstanding and highly
> appreciated, yet it comes with a long history.  I need to re-linearize
> it, split it, remove superseded experiments, extract proposed
> enhancements that are not meant to be merged yet, and extensively test
> each part.
> 
> None of that is in any way special; it is typical patch integration
> work.  What is perhaps special is that the changes are more extensive
> than many other contributions being submitted to SBCL.
> 
> They were not built^W written in one day, and I think it is appropriate for
> SBCL as a project to take a little time to review and digest them, too.
> 
> d.

The same issues arose when the Axiom project moved from SVN
to git. Under SVN we created user-related branches so various
ideas could be explored. Unfortunately these branches were
not kept to the single idea but became essentially alternative
implementations with many "features". That was clearly a project
management failure on my part.

At one point in the project we attempted to merge the branches
back into the main line. Unfortunately the development on these
branches had gotten much too complex as many ideas were 
being explored in each branch. 

A many-month effort was made to cherry pick changes that could be
merged. But cherry picking changes, while technically possible,
led to social problems as the branch maintainers wanted every
change accepted. This was not possible among the several branches,
of course. This was especially hard as there was no documentation
about the changes, making conflicts impossible to resolve.

What the "great merge" exposed was that the branch maintainers
had goals that conflicted with the stated project goals. Working
in their own branch allowed them to pursue these conflicting
goals quietly. Ultimately this led to two forks.

The lesson to learn is that branches should be based on single ideas
(e.g. swap NIL and T semantics), not on people (e.g. Bob's branch).

Another lesson: code should be merged or rejected very quickly (e.g
less than 2 weeks) otherwise the branch owner gets too attached
to their code rather than the idea so rejecting the idea is taken,
unintentionally, as a rejection of the person. Even great developers
(which Axiom had) generate ideas that get rejected.

The third lesson is that it should be up to the branch owner
to provide "diff -Naur" patches that can be smoothly applied
(actually "git diff" patches). After all, the branch owner knows the
branch code. These patches should all relate to a single feature. 

The trunk maintainer should not try to understand-and-cherry-pick.
That way lies madness, anger, and forks.

A fourth lesson is that there should be no "public" branches anymore.
These should all be local. git allows branches to be pushed and pulled
among subsets of developers without public branches.

Move the trunk now. Let the branches provide focused diff-Naur patches.

Moving from SVN to git is a great idea. I highly recommend it.

Tim Daly
Axiom Lead Developer
address@hidden