Maintaining trunk and stable branch

[Eric Siegerman]

On Mon, 2011-02-21 at 18:40 +0100, Timo wrote:
> Okey, so I'll have to make some time to some extra work after one or a
couple of commits.

Probably a good guideline (not "rule" :-)) is "merge when it
feels right".  If you've fixed a couple of buglets that aren't
getting in your own way, don't bother, but if you need the
changes in "trunk", don't hesitate to do it.  If it's been a
while, or you've accumulated a sizeable amount of small changes,
consider merging then too, but don't be dogmatic about it, unless
delaying such merges has bitten you enough that you've become
paranoid.

Also, the decision affects the revision history in trunk.  If you
like a clean history in which each mainline revision in trunk
contains only one, logically distinct change, merge often.  If
you don't care, merge less often.

Personally, I find that the advantages of frequent merges
outweigh the disadvantages, but YMMV.

> This leads to another question.
> I have 2 local branches on my computer, stable and trunk as mentioned
before, which are also on Launchpad. What should be the best and/or
easiest way to merge stable into trunk? Should I propose for merging
through Launchpad? Or can I do this with some bzr commands?

I'm not absolutely sure; my only use of Launchpad has been as an
occasional contributor of changes.  But my sense is that the
platform doesn't require you to use merge proposals; you should
be able to do the merge locally, then "bzr push" the destination
branch up to Launchpad.  Or you might have your local copy of
trunk bound to the Launchpad master copy, so that every commit to
it gets pushed up automatically.

AIUI, merge proposals don't serve a technical function, but
rather a social one:  they facilitate code reviews.

In the Bazaar project, policy is that all changes get reviewed,
so even the core team uses MPs.  There's an automated tool, Patch
Queue Manager, which I believe is the only entity with commit
permission on the project's trunk; so even core team members have
to ask PQM to merge their changes for them.  (If you look at the
change log of Bazaar's trunk,
https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev, you'll see that
every mainline revision (un-dotted revno) in the last five years
has been committed by PQM.)  One advantage of this is that on
every branch submitted to it, PQM runs the entire test suite, and
refuses to merge the branch if any tests fail.

But I can well imagine a looser project policy, in which core
contributors aren't required to have their changes reviewed.  In
such a project, the core team members would all have commit
access to trunk [1].  They would just do their commits locally
and push the results, as described above; only non-core
contributors would have to put up MPs asking core folks to review
and merge their changes.

Actually, unless your project has a gatekeeper like PQM, I
suspect that the mechanics of merging non-core contributions
would *have to* be that a core team member (1) pulls down the
proposed branch, (2) merges it locally (assuming it passes
muster), and (3) if their copy of trunk isn't bound, "bzr push"es
the results up to Launchpad.

  - Eric

[1] or just you, if your project has a "core team" of one.