Misunderstood the "Assigned" at bugs! Sorry !!!

Tobias B. Besemer

unread,

Jul 8, 2014, 9:51:32 PM7/8/14

to

Hi!

Sorry, I have since some weeks the "can-edit" at Bugzilla and misunderstood the "Assigned"!
I tried to help and clean up a bit Bugzilla with updating the "Target Milestone" to a Milestone that get still developed ... and was thinking that when a bug is "Assigned To", that then the "Status" have to be "Assigned" ...
I now realized, that this don't have to be !!!
Sorry, if I have hurt somebody with this !!!

Greets, Tobias.

Chris Peterson

unread,

Jul 9, 2014, 2:47:43 AM7/9/14

to

hi Tobias, Bugzilla has many fields and teams use them in many different
ways. :) It's usually best to let the people reporting or investigating
the bugs update the bug fields.

From my experience, many (most?) teams never change a bug's "Status"
from NEW to ASSIGNED, but they still use "Assigned To". A few teams set
both, but change "Status" from NEW to ASSIGNED when the assigned
developer actually begins to work on the bug.

Despite its name, the "Target Milestone" field is usually left unset
until *after* the bug is fixed. Then "Target Milestone" is set to the
version of Firefox Nightly that was fixed (e.g. Nightly 33 is
"mozilla33"). Even if a bug fix is uplifted from Nightly 33 to, say,
Beta 31, the "Target Milestone" would stay "mozilla33", not "mozilla
31". There must have been a good reason for this at some time, but it's
hard to say for certain.. :)

chris

Ryan VanderMeulen

unread,

Jul 9, 2014, 8:10:51 AM7/9/14

to

On 7/9/2014 2:47 AM, Chris Peterson wrote:
> Despite its name, the "Target Milestone" field is usually left unset
> until *after* the bug is fixed. Then "Target Milestone" is set to the
> version of Firefox Nightly that was fixed (e.g. Nightly 33 is
> "mozilla33"). Even if a bug fix is uplifted from Nightly 33 to, say,
> Beta 31, the "Target Milestone" would stay "mozilla33", not "mozilla
> 31". There must have been a good reason for this at some time, but it's
> hard to say for certain.. :)

It's been that way since before status flags even existed. I think it's
still useful for archeology purposes to keep "this is when it landed on
trunk" separate from "this is what branches it was uplifted to."

-Ryan

Tobias B. Besemer

unread,

Jul 9, 2014, 11:00:03 AM7/9/14

to

Am Mittwoch, 9. Juli 2014 03:51:32 UTC+2 schrieb Tobias B. Besemer:
> I tried to help and clean up a bit Bugzilla with updating the "Target Milestone" to a Milestone that get still developed ...

Gijs Kruitbosch

unread,

Jul 9, 2014, 11:16:57 AM7/9/14

to Tobias B. Besemer

On 09/07/2014 16:00, Tobias B. Besemer wrote:
> Am Mittwoch, 9. Juli 2014 03:51:32 UTC+2 schrieb Tobias B. Besemer:
>> I tried to help and clean up a bit Bugzilla with updating the "Target Milestone" to a Milestone that get still developed ...
>
> I did this:
> https://bugzilla.mozilla.org/buglist.cgi?f1=OP&f0=OP&classification=Components&emailtype1=exact&f4=CP&query_format=advanced&f3=CP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Core&target_milestone=M1&target_milestone=M2&target_milestone=M3&target_milestone=M4&target_milestone=M5&target_milestone=M6&target_milestone=M7&target_milestone=M8&target_milestone=M9&target_milestone=M10&target_milestone=M11&target_milestone=M12&target_milestone=M13&target_milestone=M14&target_milestone=M15&target_milestone=M16&target_milestone=M17&target_milestone=M18&target_milestone=mozilla0.6&target_milestone=mozilla0.8&target_milestone=mozilla0.8.1&target_milestone=mozilla0.9&target_milestone=mozilla0.9.1&target_milestone=mozilla0.9.2&target_milestone=mozilla0.9.3&target_milestone=mozilla0.9.4&target_milestone=mozilla0.9.5&target_milestone=mozilla0.9.6&target_milestone=mozilla0.9.7&target_milestone=mozilla0.9.8&target_milestone=mozilla0.9.9&target_milestone=psm2.0
&target_milestone=psm2.1&target_milestone=psm2.2&target_milestone=psm2.3&target_milestone=psm2.4&target_milestone=mozilla1.0&target_milestone=mozilla1.0.1&target_milestone=mozilla1.0.2&target_milestone=mozilla1.0.3&target_milestone=mozilla1.1alpha&target_milestone=mozilla1.1beta&target_milestone=mozilla1.1final&target_milestone=mozilla1.2alpha&target_milestone=mozilla1.2beta&target_milestone=mozilla1.2final&target_milestone=mozilla1.3alpha&target_milestone=mozilla1.3beta&target_milestone=mozilla1.3final&target_milestone=mozilla1.4alpha&target_milestone=mozilla1.4beta&target_milestone=mozilla1.4final&target_milestone=mozilla1.5alpha&target_milestone=mozilla1.5beta&target_milestone=mozilla1.5final&target_milestone=mozilla1.6alpha&target_milestone=mozilla1.6beta&target_milestone=mozilla1.6final&target_milestone=mozilla1.7alpha&target_milestone=mozilla1.7beta&target_milestone=mozilla1.7final&target_milestone=mozilla1.8alpha1&target_milestone=mozilla1.8alpha2&target_milestone=mozilla1.8alp
ha3&target_milestone=mozilla1.8alpha4&target_milestone=mozilla1.8alpha5&target_milestone=mozilla1.8alpha6&target_milestone=mozilla1.8beta1&target_milestone=mozilla1.8beta2&target_milestone=mozilla1.8beta3&target_milestone=mozilla1.8beta4&target_milestone=mozilla1.8beta5&target_milestone=mozilla1.8rc1&target_milestone=mozilla1.8rc2&target_milestone=mozilla1.8final&target_milestone=mozilla1.8.1alpha1&target_milestone=mozilla1.8.1alpha2&target_milestone=mozilla1.8.1alpha3&target_milestone=mozilla1.8.1beta1&target_milestone=mozilla1.8.1beta2&target_milestone=mozilla1.8.1&target_milestone=mozilla1.9alpha1&target_milestone=mozilla1.9alpha2&target_milestone=mozilla1.9alpha3&target_milestone=mozilla1.9alpha4&target_milestone=mozilla1.9alpha5&target_milestone=mozilla1.9alpha6&target_milestone=mozilla1.9alpha7&target_milestone=mozilla1.9alpha8&target_milestone=mozilla1.9beta1&target_milestone=mozilla1.9beta2&target_milestone=mozilla1.9beta3&target_milestone=mozilla1.9beta4&target_milestone=mozi

lla1.9beta5&target_milestone=mozilla1.9&target_milestone=mozilla1.9.1a1&target_milestone=mozilla1.9.1a2&target_milestone=mozilla1.9.1b1&target_milestone=mozilla1.9.1b2&target_milestone=mozilla1.9.1b3&target_milestone=mozilla1.9.1b4&target_milestone=mozilla1.9.1&target_milestone=mozilla1.9.2a1&target_milestone=mozilla1.9.2b1&target_milestone=mozilla1.9.2&target_milestone=mozilla1.9.3a1&target_milestone=mozilla1.9.3a2&target_milestone=mozilla1.9.3a3&target_milestone=mozilla1.9.3a4&target_milestone=mozilla1.9.3a5&target_milestone=mozilla2.0b1&target_milestone=mozilla2.0b2&target_milestone=mozilla2.0b3&target_milestone=mozilla2.0b4&target_milestone=mozilla2.0b5&target_milestone=mozilla2.0b6&target_milestone=mozilla2..0b7&target_milestone=mozilla2.0b8&target_milestone=mozilla2.0b9&target_milestone=mozilla2.0b10&target_milestone=mozilla2.0b11&target_milestone=mozilla2.0b12&target_milestone=mozilla2.0&target_milestone=mozilla5&target_milestone=mozilla6&target_milestone=mozilla7&target_milest

one=mozilla8&target_milestone=mozilla9&target_milestone=mozilla10&target_milestone=mozilla11&target_milestone=mozilla12&target_milestone=mozilla13&target_milestone=mozilla14&target_milestone=mozilla15&target_milestone=mozilla16&target_milestone=mozilla17&target_milestone=mozilla18&target_milestone=mozilla19&target_milestone=mozilla20&target_milestone=mozilla21&target_milestone=mozilla22&target_milestone=mozilla23&target_milestone=mozilla25&target_milestone=mozilla26&target_milestone=mozilla27
> ;-)
> And the set the "Target Milestone" to "---" ...
> But a lot of work ...
> My next run would be "Status = Assigned" & "Assigned To = Nob...@Mozilla.org" ...
> After that I will check my own old bugs and my votes and then look what else in Bugzilla can be "cleaned up" ... maybe the same then above on "Bugzilla" or a other component ...
> There exist no functions/scripts for this, right?
>
> Tobias.

Please don't mass change the target milestone flag on bugs (definitely
not manually). Same goes for the assignee field.

~ Gijs

Daniel Holbert

unread,

Jul 9, 2014, 11:27:31 AM7/9/14

to dev-pl...@lists.mozilla.org, Gijs Kruitbosch

>> Tobias.
>
> Please don't mass change the target milestone flag on bugs (definitely
> not manually). Same goes for the assignee field.
>
> ~ Gijs

To be clear, I don't think he's planning on mass-changing the *assignee*
field -- rather, it sounds like his next plan was to reset Status to
"NEW", for bugs that are ASSIGNED but have no assignee.

That seems like a reasonable sort of change to me. Of course, any
mass-change in Bugzilla could have unintended consequences or step on
toes in some obscure component with its own rules; but AFAIK, this
particular change seems likely to just be a change to better-reflect
reality.

(I'm not sure how much value it adds, but I don't see it doing much harm.)

~Daniel

Gijs Kruitbosch

unread,

Jul 9, 2014, 11:33:25 AM7/9/14

to Daniel Holbert

Either change should be done through a mass change that doesn't cause
bugmail, so not by a casual contributor without the right bmo
privileges. Otherwise we're just wasting (a) a lot of their and our
(collective) time, and (b) don't gain very much. :-)

I'm also not sure about whether changing the target milestone of
unclosed bugs (I'm hoping these are all unclosed bugs...) doesn't end up
losing us stuff we care about. Even if that isn't the case in our
primary products/components, we have rather a lot of them.

If people want to contribute to the state of our bugtracking db, using
mozregression with bugs that have regressionwindow-wanted set, or
creating testcases for bugs that are filed, or triaging stuff from
Fx::Untriaged into a better component (provided they have a good idea of
what component stuff goes in) is likely to be more helpful...

~ Gijs

Daniel Holbert

unread,

Jul 9, 2014, 11:35:49 AM7/9/14

to Gijs Kruitbosch, dev-platform

On 07/09/2014 08:33 AM, Gijs Kruitbosch wrote:
> Either change should be done through a mass change that doesn't cause
> bugmail, so not by a casual contributor without the right bmo
> privileges. Otherwise we're just wasting (a) a lot of their and our
> (collective) time, and (b) don't gain very much. :-)
>
> I'm also not sure about whether changing the target milestone of
> unclosed bugs (I'm hoping these are all unclosed bugs...) doesn't end up
> losing us stuff we care about. Even if that isn't the case in our
> primary products/components, we have rather a lot of them.
>
> If people want to contribute to the state of our bugtracking db, using
> mozregression with bugs that have regressionwindow-wanted set, or
> creating testcases for bugs that are filed, or triaging stuff from
> Fx::Untriaged into a better component (provided they have a good idea of
> what component stuff goes in) is likely to be more helpful...

(I agree, on all points.)

Milan Sreckovic

unread,

Jul 9, 2014, 11:45:55 AM7/9/14

to Daniel Holbert, dev-pl...@lists.mozilla.org, Gijs Kruitbosch

What’s the purpose of the “ASSIGNED" status? If we’re saying that this status can be computed from Assigned To field (being set to nobody or something else), then why do we still have it? If it isn’t equivalent, then we may be losing some information if we reset it back to New.

--
- Milan

On Jul 9, 2014, at 11:27 , Daniel Holbert <dhol...@mozilla.com> wrote:

> On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote:

>>> Tobias.
>>
>> Please don't mass change the target milestone flag on bugs (definitely
>> not manually). Same goes for the assignee field.
>>
>> ~ Gijs
>

> To be clear, I don't think he's planning on mass-changing the *assignee*
> field -- rather, it sounds like his next plan was to reset Status to
> "NEW", for bugs that are ASSIGNED but have no assignee.
>
> That seems like a reasonable sort of change to me. Of course, any
> mass-change in Bugzilla could have unintended consequences or step on
> toes in some obscure component with its own rules; but AFAIK, this
> particular change seems likely to just be a change to better-reflect
> reality.
>
> (I'm not sure how much value it adds, but I don't see it doing much harm.)
>
> ~Daniel

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Gijs Kruitbosch

unread,

Jul 9, 2014, 11:48:05 AM7/9/14

to Milan Sreckovic, Daniel Holbert

As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used
by people when they are the assignee. There is only a lack of difference
when the assignee is "nob...@mozilla.org". That doesn't warrant
abolishing the status (although we could arguably ask bmo folks to make
the "reset the assignee to default" also set the status to "new" if the
status was previously "assigned")

~ Gijs

On 09/07/2014 16:45, Milan Sreckovic wrote:
> Whatï¿½s the purpose of the ï¿½ASSIGNED" status? If weï¿½re saying that this status can be computed from Assigned To field (being set to nobody or something else), then why do we still have it? If it isnï¿½t equivalent, then we may be losing some information if we reset it back to New.

Ed Morley

unread,

Jul 10, 2014, 11:07:49 AM7/10/14

to Gijs Kruitbosch, dev-pl...@lists.mozilla.org

On 09/07/2014 16:48:05, Gijs Kruitbosch wrote:
> As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used
> by people when they are the assignee. There is only a lack of
> difference when the assignee is "nob...@mozilla.org". That doesn't
> warrant abolishing the status (although we could arguably ask bmo
> folks to make the "reset the assignee to default" also set the status
> to "new" if the status was previously "assigned")

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1036834 for
resetting the status from ASSIGNED to NEW when the assignee is reset.

Ed

Philip Chee

unread,

Jul 11, 2014, 1:29:30 AM7/11/14

to

On 09/07/2014 23:48, Gijs Kruitbosch wrote:
> As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used
> by people when they are the assignee. There is only a lack of difference
> when the assignee is "nob...@mozilla.org". That doesn't warrant
> abolishing the status (although we could arguably ask bmo folks to make
> the "reset the assignee to default" also set the status to "new" if the
> status was previously "assigned")

Then there are bugs which are ASSIGNED but with multiple assignees. For
example Bug 1027241 was a team effort [1].

[1] https://hg.mozilla.org/comm-central/rev/a900b3a64007

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

Tobias B. Besemer

unread,

Apr 7, 2015, 4:15:09 PM4/7/15

to

OK, to reopen this discussion ...

I suggested in Bug 1151371 to activate the status "IN_PROGRESS" in bmo and use this status for bugs that are "in progress" ("patch in work") and that everybody use the status "applied" in future only as "taken" or as "in the to-dos-list" like the others do.
My arguments for this and reasons can be found in the bug.
Feedback welcome.

https://bugzilla.mozilla.org/show_bug.cgi?id=1151371

Daniel Holbert

unread,

Apr 7, 2015, 5:19:22 PM4/7/15

to Tobias B. Besemer, dev-pl...@lists.mozilla.org

On 04/07/2015 01:15 PM, Tobias B. Besemer wrote:
> OK, to reopen this discussion ...
>
> I suggested in Bug 1151371 to activate the status "IN_PROGRESS" in bmo and use this status for bugs that are "in progress" ("patch in work") and that everybody use the status "applied" in future only as "taken" or as "in the to-dos-list" like the others do.
> My arguments for this and reasons can be found in the bug.

People already have inconsistent interpretations of what the bug
"status" field ASSIGNED vs NEW means (and inconsistent
levels-of-bothering-to-actually-tweak-the-flag). Adding an additional
IN_PROGRESS status will likely just make things more confusing --
particularly given that many people won't bother to set it, either
explicitly or accidentally. (Why should they? It's extra process for
process's sake, and it'd arguably be a waste of their time.)

What is the problem you're trying to solve? I think you're worried
about new contributors mistakenly thinking NEW means "unassigned"? If
that's your concern, then (to the extent that's an actual problem) I
think it'd be better to focus on surfacing the "assignee" field, and
highlighting tools like Bugs Ahoy which these contributors should be
using in the first place.

I don't think adding an additional status (which will break existing
conventions & will be applied inconsistently) is going to help here.

~Daniel

Karl Dubost

unread,

Apr 7, 2015, 7:04:34 PM4/7/15

to Daniel Holbert, dev-pl...@lists.mozilla.org, Tobias B. Besemer

Daniel,

Le 8 avr. 2015 à 06:19, Daniel Holbert <dhol...@mozilla.com> a écrit :
> People already have inconsistent interpretations of what the bug
> "status" field ASSIGNED vs NEW means (and inconsistent
> levels-of-bothering-to-actually-tweak-the-flag).

(Sorry if it had already been discussed in the past, slap me with a URI with the past archived discussion about it.)

Agreed for the ASSIGNED vs NEW is bothering to set manually.
That said I never understood, why it was not tied to someone being assigned to the bug. "Take this bug" should flip automatically this field. Going back to nobody should put it back to NEW.

--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

Tobias B. Besemer

unread,

Apr 9, 2015, 8:03:11 PM4/9/15

to

Am Mittwoch, 8. April 2015 01:04:34 UTC+2 schrieb Karl Dubost:
> Daniel,
>

> Le 8 avr. 2015 à 06:19, Daniel Holbert <dholbert@mozi**a.com> a écrit :
> > People already have inconsistent interpretations of what the bug
> > "status" field ASSIGNED vs NEW means (and inconsistent
> > levels-of-bothering-to-actually-tweak-the-flag).
>
> (Sorry if it had already been discussed in the past, slap me with a URI with the past archived discussion about it.)

I reopened the old topic.
https://groups.google.com/forum/?hl=de#!topic/mozilla.dev.platform/3DAYBckD2C4
(Maybe you have to replace the "de" with "us" or something like that ...)

> Agreed for the ASSIGNED vs NEW is bothering to set manually.
> That said I never understood, why it was not tied to someone being assigned to the bug. "Take this bug" should flip automatically this field. Going back to nobody should put it back to NEW.

Ahhmmm ... yes! Seems you don't understand the workflow from some devs like I did at the beginning ... :D
Some "Take this bug" but let the status to "NEW" to show that it is in the to-dos-list and set the status to "ASSIGNED" when a solution is _in_progress_. ^^ (AFAIK)
Think that's just a behavior from the time where "IN_PROGRESS" didn't existed ... (IMHO)

So what's my problem with?
Normally nothing ... but I didn't understand it at the beginning like I guess, others don't do it ...
One of my favs on computers (in comparison to RL) is, that if you have a problem and you fix it one time correct, normally the problem shouldn't appear again.
So I can just learn how bmo is used and us it for me ... or I try to fix "the problem" for (hopefully) everyone else, too.

And about save of time:
Really the first time that somebody had this question and started a discussion ???

I try to make a little bit QA for Mozilla ...
Mozilla measure a lot of data, telemetry, crash reports ... to have exact data to work with and don't have to guess so much because it was measured ...
... but bmo IMHO (the oldest tool?) seems to reflect the reality not at all!
I think it should be possible to e.g. making stats about bmo for QA, too.
E.g.: Which Windows 7 bug is the most annoying for the users at bmo?
Or: Which bug is the oldest not fixed bug with Importance "Major"?
I don't know if such analyses are done ATM ...
... but would be hard with data that is correct or not, or?
And the status of a bug is the simplest/first/most important data of a bug ...
So IMHO a small change for the devs/teams but a big change for QA !?