Robert,
do you have any advice on how to best keep track of what to backport to
earlier (i.e. STABLE) releases?
With the CVS changeset wrappers we had external classification and
grouping of the changesets, making it quite easy to keep track of the
backporting status of each changeset using three attributes:
- Which group of related changesets it belongs to
- If the changeset has been backported
- If the changeset is not a candidate to be backported.
Giving us three important views of the changesets
- Not yet categorized changes
- Groups of changes which are candidates to be backported
- Groups of changes which are NOT candidates to be backported
and ofcourse also the fourth view but not really relevant for any
practical purpose.
- Changes which has been backported (and their grouping)
(it's easier seen in the list of changes in the target branch)
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
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..
Regards
Henrik
