Open Stack

Thomas Goirand wrote:
> On 11/23/2015 10:58 PM, Doug Hellmann wrote:
>> 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.
> 
> So, because Launchpad is unreliable, we're going to have bad bug
> tracking. Why can't we have Launchpad fixed? Or the signaling to it
> fixed so that it retries?

It's not just Launchpad being unreliable. The automated status
transitions in Launchpad assume that people correctly link commits to
bugs in commit messages (using Closes-Bug and Implements-Blueprint).
Most of the time they do (and most of the time Launchpad does work
perfectly alright). The problem is the 10% (or 1%) caseswhere they don't.

It's a lot too brittle for us to rely on that for accurate change
tracking. I don't think that results in "bad bug tracking" though.

>> 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.
> 
> This is a good call for stopping using Launchpad, not stopping tracking
> things correctly.

We already weren't tracking things correctly. The new change tracking
system (which is based on git commits rather than whatever Launchpad
thinks has been merged) is correct.

> On 11/24/2015 05:26 PM, Thierry Carrez wrote:
>> I don't think we need to guarantee that the comment is added.
> 
> So, when I don't see the comment in a fix which I am trying to apply to
> one of my packages, I should tell myself: "oh, are we in the case of a
> timeout?" ... Gosh, this seems so broken and unreliable ... If we don't
> guarantee that the comment will be there in case of a release, then why
> bother at all to have them sent?

My point here is that currently the system doesn't completely guarantee
a bug will be updated (since it relies on humans providing links). The
new system is the same: not better, not worse. I'm not sure what you're
complaining about. We are just changing from using milestone targeting
to using messages in the bug to clearly indicate which release the
bugfix was shipped in, independently from any milestone it could be
targeted to. If anything, that will improve the results since the
addMessage() API is less prone to timeouts than the status change.

>> 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 :)
> 
> I'm not sure I am following here. Are we already using phabricator for
> bug tracking?

Using our task tracker solely for task tracking will certainly
facilitate migrating to another tool. It was pretty difficult to find a
functional equivalent to Launchpad since it combined the features of a
task tracker and a change tracker. Using Launchpad purely for task
tracking makes it easier to replace it with another task tracker.

-- 
Thierry Carrez (ttx)