[openstack-dev] [release] process change for closing bugs when patches merge

Thierry Carrez thierry at openstack.org
Tue Nov 24 16:26:19 UTC 2015


Robert Collins wrote:
> [...]
> 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.

I don't think we need to guarantee that the comment is added. In the old
system we *needed* to update the milestones and bug statuses because the
resulting milestone page was used as the official summary of everything
in the release (change management). In the new system we use other tools
for change management (git/reno) so we can tolerate omissions or
eventual consistency on the Launchpad side. It's not as much of a big
deal if a comment fails to be added, this is mostly meant as a courtesy
rather than reference material. Also I find bug.addMessage() a lot less
prone to timeouts (never hit one, even on busy bugs).

So it would be a shame to restrict task tracking possibilities to two
projects per bug just to preserve accurate change tracking in Launchpad,
while the plan is to focus Launchpad usage solely on task tracking :)

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list