Re: Misunderstood the Assigned at bugs! Sorry !!!
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
Daniel, Le 8 avr. 2015 à 06:19, Daniel Holbert dholb...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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, philip.c...@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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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 On 7/8/14 6:51 PM, Tobias B. Besemer wrote: 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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=OPf0=OPclassification=Componentsemailtype1=exactf4=CPquery_format=advancedf3=CPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Coretarget_milestone=M1target_milestone=M2target_milestone=M3target_milestone=M4target_milestone=M5target_milestone=M6target_milestone=M7target_milestone=M8target_milestone=M9target_milestone=M10target_milestone=M11target_milestone=M12target_milestone=M13target_milestone=M14target_milestone=M15target_milestone=M16target_milestone=M17target_milestone=M18target_milestone=mozilla0.6target_milestone=mozilla0.8target_milestone=mozilla0.8.1target_milestone=mozilla0.9target_milestone=mozilla0.9.1target_milestone=mozilla0.9.2target_milestone=mozilla0.9.3target_milestone=mozilla0.9.4target_milestone=mozilla0.9.5target_milestone=mozilla0.9.6target_milestone=mozilla0.9.7target_milestone=mozilla0.9.8target_milestone=mozilla0.9.9target_milestone =psm2.0target_milestone=psm2.1target_milestone=psm2.2target_milestone=psm2.3target_milestone=psm2.4target_milestone=mozilla1.0target_milestone=mozilla1.0.1target_milestone=mozilla1.0.2target_milestone=mozilla1.0.3target_milestone=mozilla1.1alphatarget_milestone=mozilla1.1betatarget_milestone=mozilla1.1finaltarget_milestone=mozilla1.2alphatarget_milestone=mozilla1.2betatarget_milestone=mozilla1.2finaltarget_milestone=mozilla1.3alphatarget_milestone=mozilla1.3betatarget_milestone=mozilla1.3finaltarget_milestone=mozilla1.4alphatarget_milestone=mozilla1.4betatarget_milestone=mozilla1.4finaltarget_milestone=mozilla1.5alphatarget_milestone=mozilla1.5betatarget_milestone=mozilla1.5finaltarget_milestone=mozilla1.6alphatarget_milestone=mozilla1.6betatarget_milestone=mozilla1.6finaltarget_milestone=mozilla1.7alphatarget_milestone=mozilla1.7betatarget_milestone=mozilla1.7finaltarget_milestone=mozilla1.8alpha1target_milestone=mozilla1.8alpha2target_milest one=mozilla1.8alpha3target_milestone=mozilla1.8alpha4target_milestone=mozilla1.8alpha5target_milestone=mozilla1.8alpha6target_milestone=mozilla1.8beta1target_milestone=mozilla1.8beta2target_milestone=mozilla1.8beta3target_milestone=mozilla1.8beta4target_milestone=mozilla1.8beta5target_milestone=mozilla1.8rc1target_milestone=mozilla1.8rc2target_milestone=mozilla1.8finaltarget_milestone=mozilla1.8.1alpha1target_milestone=mozilla1.8.1alpha2target_milestone=mozilla1.8.1alpha3target_milestone=mozilla1.8.1beta1target_milestone=mozilla1.8.1beta2target_milestone=mozilla1.8.1target_milestone=mozilla1.9alpha1target_milestone=mozilla1.9alpha2target_milestone=mozilla1.9alpha3target_milestone=mozilla1.9alpha4target_milestone=mozilla1.9alpha5target_milestone=mozilla1.9alpha6target_milestone=mozilla1.9alpha7target_milestone=mozilla1.9alpha8target_milestone=mozilla1.9beta1target_milestone=mozilla1.9beta2target_milestone=mozilla1.9beta3target_milestone=mozilla1.9 beta4target_milestone=mozilla1.9beta5target_milestone=mozilla1.9target_milestone=mozilla1.9.1a1target_milestone=mozilla1.9.1a2target_milestone=mozilla1.9.1b1target_milestone=mozilla1.9.1b2target_milestone=mozilla1.9.1b3target_milestone=mozilla1.9.1b4target_milestone=mozilla1.9.1target_milestone=mozilla1.9.2a1target_milestone=mozilla1.9.2b1target_milestone=mozilla1.9.2target_milestone=mozilla1.9.3a1target_milestone=mozilla1.9.3a2target_milestone=mozilla1.9.3a3target_milestone=mozilla1.9.3a4target_milestone=mozilla1.9.3a5target_milestone=mozilla2.0b1target_milestone=mozilla2.0b2target_milestone=mozilla2.0b3target_milestone=mozilla2.0b4target_milestone=mozilla2.0b5target_milestone=mozilla2.0b6target_milestone=mozilla2.0b7target_milestone=mozilla2.0b8target_milestone=mozilla2.0b9target_milestone=mozilla2.0b10target_milestone=mozilla2.0b11target_milestone=mozilla2.0b12target_milestone=mozilla2.0target_milestone=mozilla5target_milestone=mozilla6tar get_milestone=mozilla7target_milestone=mozilla8target_milestone=mozilla9target_milestone=mozilla10target_milestone=mozilla11target_milestone=mozilla12target_milestone=mozilla13target_milestone=mozilla14target_milestone=mozilla15target_milestone=mozilla16target_milestone=mozilla17target_milestone=mozilla18target_milestone=mozilla19target_milestone=mozilla20target_milestone=mozilla21target_milestone=mozilla22target_milestone=mozilla23target_milestone=mozilla25target_milestone=mozilla26target_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. ___ dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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=OPf0=OPclassification=Componentsemailtype1=exactf4=CPquery_format=advancedf3=CPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Coretarget_milestone=M1target_milestone=M2target_milestone=M3target_milestone=M4target_milestone=M5target_milestone=M6target_milestone=M7target_milestone=M8target_milestone=M9target_milestone=M10target_milestone=M11target_milestone=M12target_milestone=M13target_milestone=M14target_milestone=M15target_milestone=M16target_milestone=M17target_milestone=M18target_milestone=mozilla0.6target_milestone=mozilla0.8target_milestone=mozilla0.8.1target_milestone=mozilla0.9target_milestone=mozilla0.9.1target_milestone=mozilla0.9.2target_milestone=mozilla0.9.3target_milestone=mozilla0.9.4target_milestone=mozilla0.9.5target_milestone=mozilla0.9.6target_milestone=mozilla0.9.7target_milestone=mozilla0.9.8target_milestone=mozilla0.9.9target_milesto ne=psm2.0 target_milestone=psm2.1target_milestone=psm2.2target_milestone=psm2.3target_milestone=psm2.4target_milestone=mozilla1.0target_milestone=mozilla1.0.1target_milestone=mozilla1.0.2target_milestone=mozilla1.0.3target_milestone=mozilla1.1alphatarget_milestone=mozilla1.1betatarget_milestone=mozilla1.1finaltarget_milestone=mozilla1.2alphatarget_milestone=mozilla1.2betatarget_milestone=mozilla1.2finaltarget_milestone=mozilla1.3alphatarget_milestone=mozilla1.3betatarget_milestone=mozilla1.3finaltarget_milestone=mozilla1.4alphatarget_milestone=mozilla1.4betatarget_milestone=mozilla1.4finaltarget_milestone=mozilla1.5alphatarget_milestone=mozilla1.5betatarget_milestone=mozilla1.5finaltarget_milestone=mozilla1.6alphatarget_milestone=mozilla1.6betatarget_milestone=mozilla1.6finaltarget_milestone=mozilla1.7alphatarget_milestone=mozilla1.7betatarget_milestone=mozilla1.7finaltarget_milestone=mozilla1.8alpha1target_milestone=mozilla1.8alpha2target_milestone=mozi lla1.8alp ha3target_milestone=mozilla1.8alpha4target_milestone=mozilla1.8alpha5target_milestone=mozilla1.8alpha6target_milestone=mozilla1.8beta1target_milestone=mozilla1.8beta2target_milestone=mozilla1.8beta3target_milestone=mozilla1.8beta4target_milestone=mozilla1.8beta5target_milestone=mozilla1.8rc1target_milestone=mozilla1.8rc2target_milestone=mozilla1.8finaltarget_milestone=mozilla1.8.1alpha1target_milestone=mozilla1.8.1alpha2target_milestone=mozilla1.8.1alpha3target_milestone=mozilla1.8.1beta1target_milestone=mozilla1.8.1beta2target_milestone=mozilla1.8.1target_milestone=mozilla1.9alpha1target_milestone=mozilla1.9alpha2target_milestone=mozilla1.9alpha3target_milestone=mozilla1.9alpha4target_milestone=mozilla1.9alpha5target_milestone=mozilla1.9alpha6target_milestone=mozilla1.9alpha7target_milestone=mozilla1.9alpha8target_milestone=mozilla1.9beta1target_milestone=mozilla1.9beta2target_milestone=mozilla1.9beta3target_milestone=mozilla1.9beta4target_miles tone=mozi lla1.9beta5target_milestone=mozilla1.9target_milestone=mozilla1.9.1a1target_milestone=mozilla1.9.1a2target_milestone=mozilla1.9.1b1target_milestone=mozilla1.9.1b2target_milestone=mozilla1.9.1b3target_milestone=mozilla1.9.1b4target_milestone=mozilla1.9.1target_milestone=mozilla1.9.2a1target_milestone=mozilla1.9.2b1target_milestone=mozilla1.9.2target_milestone=mozilla1.9.3a1target_milestone=mozilla1.9.3a2target_milestone=mozilla1.9.3a3target_milestone=mozilla1.9.3a4target_milestone=mozilla1.9.3a5target_milestone=mozilla2.0b1target_milestone=mozilla2.0b2target_milestone=mozilla2.0b3target_milestone=mozilla2.0b4target_milestone=mozilla2.0b5target_milestone=mozilla2.0b6target_milestone=mozilla2..0b7target_milestone=mozilla2.0b8target_milestone=mozilla2.0b9target_milestone=mozilla2.0b10target_milestone=mozilla2.0b11target_milestone=mozilla2.0b12target_milestone=mozilla2.0target_milestone=mozilla5target_milestone=mozilla6target_milestone=mozilla7targ et_milest one=mozilla8target_milestone=mozilla9target_milestone=mozilla10target_milestone=mozilla11target_milestone=mozilla12target_milestone=mozilla13target_milestone=mozilla14target_milestone=mozilla15target_milestone=mozilla16target_milestone=mozilla17target_milestone=mozilla18target_milestone=mozilla19target_milestone=mozilla20target_milestone=mozilla21target_milestone=mozilla22target_milestone=mozilla23target_milestone=mozilla25target_milestone=mozilla26target_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
Re: Misunderstood the Assigned at bugs! Sorry !!!
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 dholb...@mozilla.com wrote: On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote: On 09/07/2014 16:00, Tobias B. Besemer wrote: My next run would be Status = Assigned Assigned To = nob...@mozilla.org ... 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
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. -- - Milan On Jul 9, 2014, at 11:27 , Daniel Holbert dholb...@mozilla.com wrote: On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote: On 09/07/2014 16:00, Tobias B. Besemer wrote: My next run would be Status = Assigned Assigned To = nob...@mozilla.org ... 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
