Open Stack

On 24 November 2015 at 10:58, Doug Hellmann <doug at doughellmann.com> wrote:
> As part of completing the release automation work and deprecating our
> use of Launchpad for release content tracking, we also want make some
> changes to the way patches associated with bugs are handled.
>
> Right now, when a patch with Closes-Bug in the commit message merges,
> the bug status is updated to "Fix Committed" to indicate that the change
> is in git, but not a formal release, and we rely on the release tools to
> update the bug status to "Fix Released" when the release is  made. This
> is one of the most error prone areas of the release process, due to
> Launchpad service timeouts and other similar issues. The fact that we
> cannot reliably automate this step is the main reason we want to stop
> using Launchpad's release content tracking capabilities in the first
> place.

FWIW the reason for timeouts on these bugs is very well known - we use
multi-project bugs, and there is a known performance problem in that
area of the LP code; its considered an attractive nuisance by the LP
team - federation is a superior model with more user control over
notifications and so fort.

So, if folk do want bugs to sit in fix-committed, we can address the
timeouts really very easily: one (or two tops) projects per bug. We
should do that anyway because adding a comment to a bug is also able
to timeout, so our code is still going to suffer the same fragility
and need the same robustness if we're trying to guarantee that the
comment is added.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud