-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Collins wrote: > 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.
I thought I understood that 'bzr' encouraged the "fix on the old rev and forward port" model over "backporting / cherry picking"? In the style described at: http://www.venge.net/mtn-wiki/DaggyFixes Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7FHV+gerLs4ltQ4RAugMAKCwXMnoLMtLySsn1eUOsBwk1ec7FgCgiXUL A3AOX4rqlhZJrvuyXCEABz4= =gLzm -----END PGP SIGNATURE-----
