Re: bzr stable branch maintenance and backporting

On Thu, 2008-03-27 at 23:23 +0100, Henrik Nordstrom wrote:
> Robert,
>
> do you have any advice on how to best keep track of what to backport to
> earlier (i.e. STABLE) releases?
...
> For a sensible workflow what one really wants is something like this
>
> - A changeset starts out as uncategorized
> - Multiple related changesets may be grouped (i.e. fix or later
> continuation on an earlier commit)
> - Voting on a group of changes for categorizing the group as either
> * "to be backported"
> * "not to be backported"
> * "maybe backported when more complete"
> (no default until some opinions have been voiced)
> - Voting on a group MAY be reopened later on request
> - A backport gets reverted if it's status gets changed

So, for changeset id, I suggest we use the revision id of the commit of
a change to trunk. bzr doesn't yet, but will soon, be able to report on
'has been backported' by the use of cherry pick merges. Beyond that bzr
really has nothing build around this, but it looks like an interesting
thing to build and have.

> just trying to figure out how much bzr can support this, an how much
> needs to be built externally in separate trackers.
>
> The simple changeset framework we used for CVS is far from perfect and
> do not 100% reflect the above requirements, but still worked out
> reasonably well making sure that changes flows nicely and orderly from
> HEAD branches down to the active stable branches. We now need to get a
> similar workflow running for the bzr setup..

I'd probably start with the cvs one but use bzr's superior facilities
for obtaining changesets.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.