Open Stack

On Wed, 13 Aug 2014 12:46:03 AM Kevin Benton wrote:
> I'm not sure what the guideline is, but I would like to point out a good
> reason to have the bug report even for obvious fixes.
> When users encounters bugs, they go to launchpad to report them. They don't
> first scan the commits of the master branch to see what was fixed. Having
> the bug in launchpad provides a way to track the status (fixed, backported,
> impact, etc) of the bug and reduces the chances of duplicated bugs.

Aha, I didn't realise there were people interested in the state of the code 
but following only bugs and not review/commit logs.  In particular release 
backporting.  Good to know!

> Can you provide an example of a patch that you felt was trivial that a
> reviewer requested a bug for so we have something concrete to discuss and
> establish guidelines around?

Here's one that fixes unittests in the presence of HTTP_PROXY:
https://review.openstack.org/#/c/110853/
(I see I haven't filed the bug report for that yet, I'll do that now)

.. and another that is removing an unused argument to a function:
https://review.openstack.org/#/c/111180/
I _think_ the intention here was to have a discussion of implementation impact 
on the bug rather than in the review(?) but that discussion hasn't moved 
(yet).


To be clear: I'm perfectly happy to file an accompanying bug for each change 
(_every_ change if desired!).
I want to make sure my accompanying bug reports are as useful as they can be, 
so I'm trying to learn how and when they're used.  At the moment I'm basically 
waiting until a reviewer asks for one and then copying the change description 
and a prose version of the initial patch into a new bug report.

-- 
 - Gus