Open Stack

Excerpts from Thierry Carrez's message of 2015-11-25 10:19:44 +0100:
> 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.

We've also been living with the Launchpad issues for a while, and
they're becoming worse as the number of projects we have grows. As
Robert pointed out, some of this is because we're using Launchpad
"wrong" but that just highlights another reason to move to a different
tool for tracking: Tracking changes accurately is work and currently
requires a lot of manual fiddling. We want to try to make that
simpler, less manual, and more reviewable.

> 
> >> 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.

+1

Doug