qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Branches and Merging
Date Mon, 24 Sep 2007 10:44:03 GMT
At the present time, it is useful to think of M2 as a release branch nearing
the end of its life cycle. Apply patches to M2.1 to try them out and
selectively merge onto M2, once you are happy with them. Of course, as M2
becomes a historical branch, we may apply patches to it that we discover
post-M2, that we want to merge back into either trunk or M2.1, so merge
tracking has now been turned on in that direction too.

At the moment we have:

Dev branches:

trunk
branches/M2.1

Release branches:

branches/M2

Easiest approach, when doing non-trunk work, is to work on M2.1, and merge
onto trunk. Selectively merge onto M2, if it is a patch needed for the M2
release.

It is extremely helpful when committing a patch, to ensure that an Apache
JIRA exists for the patch, and to put the number in the logs. Like this:

QPID-123 Fixed the annoying bug...

Then merge it accorss with svnmerge, and use the
svnmerge-commit-message.txtfile that it generates as the commit log
for the merge. This file contains
both the logs, and consequently the QPID-XXX numbers, as well as the actual
merged revision numbers. Mostly, people have done it liek this, but there
are a couple of cases where patches have been applied manually, with no JIRA
and under different log messages on different branches.

It would also assist matters, if people took note of these things, and did
their own merging, immediately upon submitting patches. I do not like
back-logs of un-merged patches because it is a real headache to figure out.
What happens when we do a release and we are not sure which JIRAs have been
fixed in which branch? What happens when you apply a patch to a release
branch, which is a valuable code fix, but fail to merge it back into a
development branch, so that the bug re-emerges in a future release?

Rupert

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message