Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Setting status flags on tracked bugs fixed on m-c

53 views
Skip to first unread message

Alex Keybl

unread,
Sep 12, 2012, 3:37:37 PM9/12/12
to mozilla.dev.planning group
I wanted to follow up on a conversation in bug 783405, since I don't believe it's been communicated here before. When working on a bug tracked for the version of Firefox on mozilla-central, please set the status flag to fixed for that version when resolved (in addition to the target milestone and bug resolution). Using the target milestone and bug state in addition to status flags when constructing tracking queries can really confuse things and makes it more difficult for others to easily query. Thanks!

-Alex

Ed Morley

unread,
Sep 12, 2012, 3:57:53 PM9/12/12
to
On Wednesday, 12 September 2012 20:37:37 UTC+1, Alex Keybl wrote:
> I wanted to follow up on a conversation in bug 783405, since I don't believe it's been communicated here before. When working on a bug tracked for the version of Firefox on mozilla-central, please set the status flag to fixed for that version when resolved (in addition to the target milestone and bug resolution). Using the target milestone and bug state in addition to status flags when constructing tracking queries can really confuse things and makes it more difficult for others to easily query. Thanks!
>
>
>
> -Alex

This is the first time I've seen this change in procedure mentioned - but happy to do what I can to make release-driver's lives easier :-)

I've filed a bug to get this changed in the tool used to mark bugs after mozilla-inbound merges. I presume no-one would object if the tool set status-firefoxN:fixed for all bugs, not just those marked tracking? (to avoid adding yet another egde case to have to deal with)

Cheers,

Ed

Justin Lebar

unread,
Sep 12, 2012, 4:16:30 PM9/12/12
to Ed Morley, dev-pl...@lists.mozilla.org
> I've filed a bug to get this changed in the tool used to mark bugs after mozilla-inbound merges. I presume no-one would object if the tool set status-firefoxN:fixed for all bugs, not just those marked tracking? (to avoid adding yet another egde case to have to deal with)

Could we then stop setting the target milestone? Otherwise we have
yet another edge case to deal with when the target milestone disagrees
with the tracking flags.

We'd want to stop setting target milestone at the same time as we
switch version numbers, so there's no confusion about there being a
partially used "mozilla18" target milestone.
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Ryan VanderMeulen

unread,
Sep 12, 2012, 4:27:16 PM9/12/12
to
On 9/12/2012 4:16 PM, Justin Lebar wrote:
>> I've filed a bug to get this changed in the tool used to mark bugs after mozilla-inbound merges. I presume no-one would object if the tool set status-firefoxN:fixed for all bugs, not just those marked tracking? (to avoid adding yet another egde case to have to deal with)
>
> Could we then stop setting the target milestone? Otherwise we have
> yet another edge case to deal with when the target milestone disagrees
> with the tracking flags.
>
> We'd want to stop setting target milestone at the same time as we
> switch version numbers, so there's no confusion about there being a
> partially used "mozilla18" target milestone.

If you're talking about setting the target milestone when landing on
inbound, that requirement was already dropped a couple months ago. The
tool we use for resolving bugs after merging to m-c handles setting it.

Justin Lebar

unread,
Sep 12, 2012, 4:34:16 PM9/12/12
to Ryan VanderMeulen, dev-pl...@lists.mozilla.org
> If you're talking about setting the target milestone when landing on
> inbound, that requirement was already dropped a couple months ago. The tool
> we use for resolving bugs after merging to m-c handles setting it.

No, I was suggesting that the target milestone should simply not be
set, by the automated tool or otherwise, because it would duplicate
the status-firefox-N status.

That said, it looks like we delete / hide the status-firefox-N flags
once version N is obsolete. So that's a good reason to keep the
target milestone around...

Ehsan Akhgari

unread,
Sep 12, 2012, 8:50:30 PM9/12/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Ryan VanderMeulen
On 12-09-12 4:34 PM, Justin Lebar wrote:
>> If you're talking about setting the target milestone when landing on
>> inbound, that requirement was already dropped a couple months ago. The tool
>> we use for resolving bugs after merging to m-c handles setting it.
>
> No, I was suggesting that the target milestone should simply not be
> set, by the automated tool or otherwise, because it would duplicate
> the status-firefox-N status.

That makes a lot of sense. In fact, I'd go one step further and say
that we should probably hide that field for Firefox/Toolkit/Core at least.

> That said, it looks like we delete / hide the status-firefox-N flags
> once version N is obsolete. So that's a good reason to keep the
> target milestone around...

I'm pretty sure we don't delete them, we just hide them. But I also
think that is something that we can change, given that in the long past
we used to preserve the flags that were now obsolete, just made them
non-editable.

Who wants to file the BMO bug? :-)

Cheers,
Ehsan

L. David Baron

unread,
Sep 12, 2012, 11:46:02 PM9/12/12
to Ehsan Akhgari, dev-pl...@lists.mozilla.org, Justin Lebar, Ryan VanderMeulen
One problem with the way we make fields non-editable is that we end
up with flags set that record how things were, but if somebody
accidentally or maliciously unsets them, we can't set them back the
way they were.

I'm not sure if there's anything good we can do about that, though.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

Byron Jones

unread,
Sep 13, 2012, 12:49:56 AM9/13/12
to Ehsan Akhgari, L. David Baron, dev-pl...@lists.mozilla.org
Ehsan Akhgari wrote:
>> That said, it looks like we delete / hide the status-firefox-N flags
>> once version N is obsolete. So that's a good reason to keep the
>> target milestone around...
> I'm pretty sure we don't delete them, we just hide them.
correct -- if a value isn't already set the field won't be visible.
> But I also think that is something that we can change, given that in
> the long past we used to preserve the flags that were now obsolete,
> just made them non-editable.
there's currently 10 status_firefox\d+ obsolete fields (+1 every six
weeks); which is a fair amount to add to an already complicated bugzilla
ui; but there's no technical reason why we can't stop obsoleting these
fields.

do we need to display the full list to all users with editbugs?

L. David Baron wrote:
> One problem with the way we make fields non-editable is that we end up
> with flags set that record how things were, but if somebody
> accidentally or maliciously unsets them, we can't set them back the
> way they were. I'm not sure if there's anything good we can do about
> that, though. -David
we could make obsoleted tracking/status flags read-only, or only
editable by a subset of users.


--
byron - irc:glob - bugzilla.mozilla.org team -

akeybl

unread,
Sep 13, 2012, 1:13:27 AM9/13/12
to ehsan....@gmail.com, justin...@gmail.com, dev-pl...@lists.mozilla.org, rya...@gmail.com
If we do this, we should all agree that when status-firefox(n) is set to fixed, the bug is resolved, and status-firefox(n+1) is unset, it's implied that Firefox(n+1) is fixed as well. That's the one thing that the target milestone implies but the status flags do not currently. Might be obvious, but wanted to get it down nonetheless.

-AlexEhsan Akhgari <ehsan....@gmail.com> wrote:On 12-09-12 4:34 PM, Justin Lebar wrote:
>> If you're talking about setting the target milestone when landing on
>> inbound, that requirement was already dropped a couple months ago. The tool
>> we use for resolving bugs after merging to m-c handles setting it.
>
> No, I was suggesting that the target milestone should simply not be
> set, by the automated tool or otherwise, because it would duplicate
> the status-firefox-N status.

That makes a lot of sense. In fact, I'd go one step further and say
that we should probably hide that field for Firefox/Toolkit/Core at least.

> That said, it looks like we delete / hide the status-firefox-N flags
> once version N is obsolete. So that's a good reason to keep the
> target milestone around...

I'm pretty sure we don't delete them, we just hide them. But I also
think that is something that we can change, given that in the long past
we used to preserve the flags that were now obsolete, just made them
non-editable.

Who wants to file the BMO bug? :-)

Cheers,
Ehsan

Ehsan Akhgari

unread,
Sep 13, 2012, 8:30:00 AM9/13/12
to Byron Jones, L. David Baron, dev-pl...@lists.mozilla.org
On 12-09-13 12:49 AM, Byron Jones wrote:
>> But I also think that is something that we can change, given that in
>> the long past we used to preserve the flags that were now obsolete,
>> just made them non-editable.
> there's currently 10 status_firefox\d+ obsolete fields (+1 every six
> weeks); which is a fair amount to add to an already complicated bugzilla
> ui; but there's no technical reason why we can't stop obsoleting these
> fields.

Not all of those flags are set on every bug, right? Typically only
three of them will be set for things which have landed on trunk, aurora
and beta at the time.

> do we need to display the full list to all users with editbugs?

No, only the flags that were set in the past, plus the current 4.

> L. David Baron wrote:
>> One problem with the way we make fields non-editable is that we end up
>> with flags set that record how things were, but if somebody
>> accidentally or maliciously unsets them, we can't set them back the
>> way they were. I'm not sure if there's anything good we can do about
>> that, though. -David
> we could make obsoleted tracking/status flags read-only, or only
> editable by a subset of users.

I think they should be read-only.

Cheers,
Ehsan

Graeme McCutcheon

unread,
Sep 14, 2012, 5:49:23 AM9/14/12
to
I've landed a patch for m-cMerge - it will now set the relevant status
flag when the tracking flag is set for pushes to
(mozilla|comm)-(central|aurora|beta|esrN) trees. This will only happen
when the status flag is unset or 'affected'.

Full details at
http://www.graememcc.co.uk/2012/09/14/m-cmerge-and-status-flags/

Graeme
--
http://www.graememcc.co.uk
0 new messages