Open Stack

On Mon, 2013-08-19 at 14:38 -0300, Thierry Carrez wrote:
> Note that in some cases, some "improvements" that do not clearly fall
> into the "bug" category are landed without a blueprint link (or a bug
> link). So a first step could be to require that a review always
> references a bug or a blueprint before it's landed. Then, improve the
> quality of the information present in said bug/blueprint.

I think that a "every review must reference a bug or blueprint" rule
would encourage more of this process checkbox behaviour.

Blueprints are useful for some things:

  - where a longer design rationale than is appropriate for a commit 
    message is required
  - where it's a feature we want to raise awareness around
  - where it's something that's going to take a while to bake and we 
    need to track its progress
  - etc.

(We've seen already how DocImpact can be used to obviate the need for
"docs folks should look at this" use case. We could do similarly for
QA.)

And for bugs:

  - where the person with info about a problem isn't the person fixing 
    it
  - where there's important background information (like detailed logs) 
    which can't be summarized appropriately in a commit message
  - where we want it tracked as a must-have for a given release
  - etc.

So, I'm totally fine with someone showing up with a standalone commit
(i.e. no bug or blueprint) and a nice explanatory commit message, if the
bug or blueprint would not provide any of the value listed above.

Where a bug or blueprint doesn't provide such value, you often see
people with terse commit messages referencing a process checkbox bug or
blueprint ... and that isn't helping anything.

Cheers,
Mark.