The push-for-review workflow
gustavo.niemeyer at canonical.com
Thu Sep 1 17:59:08 UTC 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.
> 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!
It certainly does.
-- I never filed a patent.
More information about the Ensemble