Open Stack

On 2014-07-24 05:51:07 -0400 (-0400), Pavel Sedlak wrote:
> Hi, my colleague Jaroslav pointed out,
> that his change did not get properly linked to, from launchpad bugs.
> 
> Review https://review.openstack.org/#/c/105105/ should get links in
> https://bugs.launchpad.net/python-novaclient/+bug/1227694
> https://bugs.launchpad.net/python-novaclient/+bug/1343991
> 
> None of them got link comment.
[...]

Looking at https://review.openstack.org/#/c/105105/1//COMMIT_MSG (the
commit message of the initial patchset, only bug 1227694 was
referenced originally and so only it would have been updated.
However, at the time that change was created (July 7), the
openstack-hudson user in Launchpad was not a member of the bug
supervisor group for python-novaclient and as a result, when it
attempted to update and assign that bug to Jaroslav, it was rejected
by the LP API and so failed to even leave a comment. See
http://lists.openstack.org/pipermail/openstack-dev/2014-July/040235.html
for further detail.

> I've figured out jeepyb/cmd/update_bug.py could be responsible for this,
> and called as gerrit local hook on change/patchset.
> Is that correct please?
[...]

Yes.

> update_bug.py in jeepyb seems to depend on connection to LP and to
> local repo, quite heavily, any suggestion how to try it in dry-run
> mode localy (without rewriting all the code)?
[...]

You'd need to create a test project on LP, though the rest you
should be able to simulate by looking at the Gerrit 2.8 hook
documentation. But more generally, as LP API calls/connections have
a tendency to be fragile, it's sometimes not possible to determine
exactly why that hook script failed to update a particular bug.

> I've found that comment for proposed fix happens only for first
> patchset.
> 
> I think I understand why (not spamming with same change again and
> again), but, as in this change, new bug numbers may be added to
> commit msg later, was it considered to try to do something like
> 'go over older comments and send new one if this change was not
> yet mentioned in them'? Would it be too expensive thing to do (in
> regards to for ex. time, requests to lp, ...)?

I think it's mostly never been improved in that regard simply due to
lack of interest from anyone willing to write the necessary patches
and thoroughly test them. Also at this point we're hanging our hopes
on Storyboard and are looking forward to retiring the LP interfacing
code in our systems, so I suspect the number of potential people
willing to spend time improving that existing implementation (if
there were any to begin with) are dwindling further as the
replacement nears readiness.
-- 
Jeremy Stanley