The push-for-review workflow

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Thu Sep 01 10:59:08 -0700 2011:
> > 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).
> 
> I'm entirely with you here. Ideally all bugs should be filed upfront
> so that we can tell at any point what's happening _right now_.
> 
> There's a small gotcha with attempting to push this approach too
> strongly, though: by enforcing that all branches be about existing
> bugs, we're also unintendedly asking everyone to not split work into
> smaller branches once it's understood that there's a nice independent
> unit of work that could be evaluated on its own.  Smaller branches,
> faster reviews, less arguments, more merges, more progress, etc.
> 
> That's the background of the push-proposal tool. If we can make it
> extremely easy to push things, it's much more likely we'll be
> comfortable with doing so more often. I also intend to have a
> -not-ready flag in push-proposal, so that it goes most of the way but
> does not mark the branch as Needs Review yet.
> 

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.

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.