mbp at canonical.com
Mon Oct 13 01:35:26 BST 2008
On Mon, Oct 13, 2008 at 9:41 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> the linux kernel developers have a tool, called linux-next (e.g.
> I'm currently working on a upgrade to the inventory representation in
> bzr which while conceptually simple is likely to have wide ranging
> impact in terms of finding assumptions about how inventories work; Aaron
> is working on a bunch of tree merge logic and others on other things, so
> the things that aren't baked yet. I'm wondering if a bzr-next mini
> project would be useful?
It seems to me that what's happening there is some of the merges are
done by people who would not otherwise be involved in development, so
it's scaling up the problem and the effort. This would clearly be a
win if someone not currently involved in development decides to both
run the tool and look into any merge or test failures. If it's people
who are working on bzr redirecting their efforts then I think it's
more questionable, and I'd rather get each individual thing merged
into bzr.dev more quickly and then merged out from there.
> Basically what it would be is:
> - a plugin
> - a branch
> - a chroot somewhere doing a test run regularly (perhaps windows too)
> The plugin would list a number of branches to merge. e.g.
> my repository branch
> nominated branches from Aaron, John, Martin, etc etc etc
> It would then (e.g. from cron, or watching the branches for changes)
> merge all the branches in, putting failure notices somewhere visible
> (and skipping the failed branch). Then run the test suite (and perhaps
> Branches that don't merge can be fixed by merging back from the bzr-next
> tree to resolve whatever issue has occurred, and telling it to merge
> that resolution. Some thought needed on making that easy.
Right, if you actually merged back from this branch then their history
would get tangled together. Presumably we actually want them to stay
separate but compatible.
More information about the bazaar