Restoring MOVED resolution in bugzilla.mozilla.org

[Emma Humphries]

In the past we had a MOVED resolution for bugs which we stopped using.

Given the number of pieces of Firefox being built in GitHub and other
systems which may be using their own bug trackers, it is worthwhile to
allow that resolution.

If your part of the project creates a BMO tracking bug for bugs you track
internally, don't use this resolution, resolve the bug as you would
normally.

If your project lands code in Mozilla-Central under a separate merge ticket
in BMO, but individual bugs are tracked in your own bug tracker, use this
resolution and in the See Also field put a link to the successor bug.

If your project does not land code in Mozilla-Central, and you use your own
bug tracker, use this resolution and in the See Also field put a link to
the successor bug.

I'll leave this discussion open through Friday, the 30th, and if there's no
substantive changes warranted, I'll enable MOVED as a resolution on Monday,
April 2nd, start tracking bugs resolved MOVED that don't point to a ticket
on another issue tracker using the See Also field.

-- Emma
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Kevin Brosnan]

Am I understanding the flow correctly?

Example bug: Summary: "Stylo Merge 2018-03-30" and when it is landed
in mozilla-central the bug is set to Status: resolved  Resolution:
moved

The second part I am having trouble understanding the flow it is not
clear when someone (a bot?) should set the bmo bug to Status: resolved
Resolution: moved

> If your project does not land code in Mozilla-Central, and you use your own bug tracker, use this resolution and in the See Also field put a link to the successor bug.

Moved makes me think we are moving bugs out of bugzilla not in.
Looking at history previous usage was moving bugs from bmo to an
internal Netscape tracker. I expected this announcement to be about
moving bugs that were filed in bmo first to GitHub. Has 'upstream'
been considered?

Kevin Brosnan





On Mon, Mar 26, 2018 at 6:01 PM, Emma Humphries <[hidden email]> wrote:

> In the past we had a MOVED resolution for bugs which we stopped using.
>
> Given the number of pieces of Firefox being built in GitHub and other
> systems which may be using their own bug trackers, it is worthwhile to allow
> that resolution.
>
> If your part of the project creates a BMO tracking bug for bugs you track
> internally, don't use this resolution, resolve the bug as you would
> normally.
>
> If your project lands code in Mozilla-Central under a separate merge ticket
> in BMO, but individual bugs are tracked in your own bug tracker, use this
> resolution and in the See Also field put a link to the successor bug.
>
> If your project does not land code in Mozilla-Central, and you use your own
> bug tracker, use this resolution and in the See Also field put a link to the
> successor bug.
>
> I'll leave this discussion open through Friday, the 30th, and if there's no
> substantive changes warranted, I'll enable MOVED as a resolution on Monday,
> April 2nd, start tracking bugs resolved MOVED that don't point to a ticket
> on another issue tracker using the See Also field.
>
> -- Emma
>
> _______________________________________________
> firefox-dev mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/firefox-dev
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Dylan Hardison]

Sorry I didn't chime in until after the fact, but it's not acceptable to have this on yet without testing / QA.

Especially not good to do this right after the big migration.

> On Mar 26, 2018, at 21:01, Emma Humphries <[hidden email]> wrote:
>
> In the past we had a MOVED resolution for bugs which we stopped using.
>
> Given the number of pieces of Firefox being built in GitHub and other systems which may be using their own bug trackers, it is worthwhile to allow that resolution.
>
> If your part of the project creates a BMO tracking bug for bugs you track internally, don't use this resolution, resolve the bug as you would normally.
>
> If your project lands code in Mozilla-Central under a separate merge ticket in BMO, but individual bugs are tracked in your own bug tracker, use this resolution and in the See Also field put a link to the successor bug.
>
> If your project does not land code in Mozilla-Central, and you use your own bug tracker, use this resolution and in the See Also field put a link to the successor bug.
>
> I'll leave this discussion open through Friday, the 30th, and if there's no substantive changes warranted, I'll enable MOVED as a resolution on Monday, April 2nd, start tracking bugs resolved MOVED that don't point to a ticket on another issue tracker using the See Also field.
>
> -- Emma

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Dylan Hardison]

Just a brief update -- MOVED is enabled on *bugzilla-dev* and will be enabled on production
as soon as we do a brief bit of QA; it's not likely to break anything. I suspect it will re-re-return
UTC April 12th unless we find something that doesn't expect new resolutions to be added.

Note this is a concern not for BMO, but for infrastructure that talks to bmo, including phabricator.
As far as BMO is concerned, you can have bug status called RUN and a resolution of AWAY, and "resolve" bugs as RUN AWAY.

> On Apr 11, 2018, at 11:46, Dylan Hardison <[hidden email]> wrote:
>
> Sorry I didn't chime in until after the fact, but it's not acceptable to have this on yet without testing / QA.
>
> Especially not good to do this right after the big migration.
>
>> On Mar 26, 2018, at 21:01, Emma Humphries <[hidden email]> wrote:
>>
>> In the past we had a MOVED resolution for bugs which we stopped using.
>>
>> Given the number of pieces of Firefox being built in GitHub and other systems which may be using their own bug trackers, it is worthwhile to allow that resolution.
>>
>> If your part of the project creates a BMO tracking bug for bugs you track internally, don't use this resolution, resolve the bug as you would normally.
>>
>> If your project lands code in Mozilla-Central under a separate merge ticket in BMO, but individual bugs are tracked in your own bug tracker, use this resolution and in the See Also field put a link to the successor bug.
>>
>> If your project does not land code in Mozilla-Central, and you use your own bug tracker, use this resolution and in the See Also field put a link to the successor bug.
>>
>> I'll leave this discussion open through Friday, the 30th, and if there's no substantive changes warranted, I'll enable MOVED as a resolution on Monday, April 2nd, start tracking bugs resolved MOVED that don't point to a ticket on another issue tracker using the See Also field.
>>
>> -- Emma
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning