Re: Release branch plans

[Glenn Morris]

I hope replies with more than one sentence are allowed...

If I can try to summarize:

The current way things work is:

There is a trunk and a release branch.

Ideally, changes appropriate to the release get made on the release
branch and then merged to the trunk. This is fine.

Sometimes, a change is made on the trunk, and then it is realized
after that fact that it needs to be on the release branch too. So it
gets committed there by hand, with a label "do not merge to trunk", or
"backport from trunk". This is less fine, because when the branch gets
merged to the trunk, you have to merge every commit (essentially), even
the ones that came from the trunk originally. So the same commit "shows
up twice" on the trunk. This is a minor annoyance (IMO).

The new proposal is presumably to commit everything on the trunk, and
label those things that need to also go to the release branch in some
way (eg "merge to emacs-24 branch"). Then use bzrmerge.el to merge from
trunk to branch, skipping everything not so labelled. This would work.
It would be slightly more effort because trunk will see more commits
than the release branch, so there are more revision to "skip" when
merging.

The log of the release branch would be essentially useless (IMO). Every
single commit would be "merge from trunk", with very few of the merged
commits having actually been applied. This is the opposite of the
current situation, where most of the merge commits are actually
applicable (it's just the backports that are not).

So I think it would be worse than the current situation.


IIRC, at this point, some wacky (IMO) three branch proposal usually
comes up...