Open Stack

Hi Doug!

Thanks for taking the time to gather opinions before going ahead.

On 11/23/2015 10:58 PM, Doug Hellmann 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.

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?

I've been told (during the Storyboard session in Tokyo) that debbugs is
a bad choice, because people don't know how to use email. Well, at
least, it has version tracking, and the email protocol is by its nature
asynchronous, and there are retries...

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

> Please let me know if this change would represent a significant
> regression to your project's workflow.

As long as there's a comment left in the bug, that's fine for *my*
workflow as a package maintainer.

Though I still believe that having to deal with such Launchpad's
deficiency this way is very frustrating. I have no doubts that you have
little choice here, otherwise you wouldn't propose it.

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?

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

Cheers,

Thomas Goirand (zigo)