[openstack-dev] Stats on blueprint design info / creation times
markmc at redhat.com
Tue Aug 20 15:58:46 UTC 2013
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
(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
And for bugs:
- where the person with info about a problem isn't the person fixing
- 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
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.
More information about the OpenStack-dev