The push-for-review workflow

Michael Nelson absoludity at
Thu Sep 1 19:48:38 UTC 2011

On Thu, Sep 1, 2011 at 9:25 PM, Clint Byrum <clint at> wrote:

> I like this a lot, and I have to agree that there's a need for lightweight
> task tracking. Bugs don't associate to each other very well, so breaking
> one big bug up into multiple branches that ultimately lead to the bug
> being fixed isn't really obvious.

Hrm - I totally agree about the bug associations, but for many multi-branch
tasks, I don't see the need for multiple bugs that associate, when you can
simply attach all the branches to the same bug like:

That wouldn't be possible if you're creating a new bug for each branch that
is pushed (rather than pushing branches which are already associated with a
bug via `bzr commit --fixes lp:12345`.). So +1 to your suggestion below
which allows either option :)

But yes, multiple-branches-per-bug doesn't help for larger features that are
spread across multiple bugs (we currently manually tag the related bugs for
that like you suggest).


> Monty Taylor has been showing me OpenStack's integration of
> git+gerrit+launchpad, and one thing they do is have the "big things"
> in blueprints, and git branches/reviews tracked inside the blueprint
> whiteboard as tasks. This gives you one place to look at the status
> of something big that is in progress, without having to jump between
> multiple bugs that have no obvious relationship.
> Seems that a nice feature that would do the same thing for this workflow
> would be to attach these branches and newly created bugs to either a tag,
> or a blueprint, if one was specified. So..
> push-review ensemble-orchestra-integration
> If there was an existing --fixes bug, it would be attached to
> ensemble-orchestra-integration, and if there was no bug, then it would
> be created and attached. Alternatively it could work backwards, if the
> branch was connected to a blueprint already, then the bugs created would
> be attached to it, and vice-versa.
> The point is that just throwing a bug out there with no attachment to
> other artifacts is actually a pretty good first step. A nice refinement
> would be to help relate those bugs together with blueprints and/or tags.
> --
> Ensemble mailing list
> Ensemble at
> Modify settings or unsubscribe at:

Michael Nelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ensemble mailing list