[Python-Dev] Mercurial migration: progress report (PEP 385)

[Stephen J. Turnbull]

Georg Brandl writes:

 > What I really want to see is the common-subset approach for
 > maintenance branches.

IMO, this unfortunately unlikely to work as you seem to expect, for a
two technical reasons and for a social reason.  The first technical
reason is that a maintenance branch really is a branch, not a subset.
The fix that is appropriate for a maintenance branch is often
inappropriate in detail for the mainline, and vice versa.  But
Mercurial doesn't care about "in detail" vs. "in design"; both will
result in a conflict the first time that branch is merged.

Second, some fixes for the maintenance branch will simply not be
appropriate for the development branch, as the problem has already
been fixed "en passant" by some other change.  This can probably be
handled by doing what git calls an "ours" merge to make it look like
the unnecessary patch is an ancestor of the tip, even though no code
was actually applied to the mainline.  However, this kind of operation
is some what delicate, and even if it's mostly scripted, it's likely
to be somewhat unreliable for people who don't use the script very
often ... which leads to the social problem:

 > > - our committers consistently refuse to merge changes across
 > >   branches themselves, and likely continue to do so unless there
 > >   is some feature of hg that I missed (e.g. one were merging
 > >   would happen without any user specifically asking for it)
 > 
 > If the checkin is done in the proper (the maint) branch, at least merging
 > of that change is automatic whenever someone does a hg merge.

Maybe.  But I see two problematic sides to this from the social point
of view, which is the same old problem really.

First, to the extent that it doesn't run into the technical problems,
it encourages people to *not* review patches for each branch they are
committed to.  "It will get automerged anyway."  Anything that
discourages review is a bad thing.  It will cause the development
branch to "age" faster because of accumulation of crufty patches that
are good enough as minimally invasive fixes for bugs in a maintenance
branch, but which should be more robust for the development branch.

I think you will also find that some people are not particularly
interested in fixing the maintenance branch for some of their patches
for exactly the same reasons they currently don't, and they will
continue to refuse to do the work to commit in the maintenance branch
first.  Especially after the first time they run into one of the
technical problems described above.

In the end, any policy to encourage a "subset" policy is likely to end
up as a burden on the same people who currently do the cross branch
merging.