The push-for-review workflow

Michael Nelson absoludity at
Thu Sep 1 17:35:00 UTC 2011

On Thu, Sep 1, 2011 at 5:22 PM, Gustavo Niemeyer
<gustavo.niemeyer at> wrote:
>> Out of interest, why are you creating a bug when submitting every
>> branch, rather than creating a branch to address a bug. If it's
>> feature work, is the bug just for recording the commit for QA? I have
>> done that when planning new features - creating bugs to split the work
>> up and then implementing it, but it seems (at least to me) that
>> something is wrong if we're creating a bug for every branch that we
>> push?
> Agreed, there's something suspicious about it depending on how one
> looks at the problem. If one looks at the Launchpad bug tracker as
> containing _bugs_, then it's clear we're abusing the system.
> That said, the way I've learned to look at bug trackers is that they
> contains tasks rather than bugs, and that's something that we need
> within a project in one form or another.  When we take that view, then
> it starts to make more sense to have one bug per branch.. the task
> tracker is what enables us to take a wider view and see everything
> that is going on in the project, not only now but that is still
> pending and that has already been finished.
> That kind of stanza enables us to create views like this:

Yep, I'm used to using bugs as tasks in LP or other trackers, what
threw me was that the script seems to be creating the task (bug)
*after* pushing the branch, rather than pushing a branch which LP will
automatically link to a previously defined task/bug (using the --fixes
lp:1234 option when committing).

>From your kanban board, the bugs certainly seem well defined, but I'm
still wondering what is defining the branches that you're working on
before you push them, given that the bug/task doesn't exist at that
point (in LP, at least)?

Hope that makes sense!

More information about the Ensemble mailing list