Bugzilla Workflow
Gervase Markham
the Bugzilla workflow:
http://steelgryphon.com/testcases/bugzilla-workflow-9.png
https://wiki.mozilla.org/BugzillaWorkflowImprovements
There were two key proposals:
- Make canconfirm able to mark as DUPLICATE and WORKSFORME
https://bugzilla.mozilla.org/show_bug.cgi?id=314056
(RESOLVED FIXED as a b.m.o. patch in December 2007)
- Add a new READY state which goes between NEW and ASSIGNED
https://bugzilla.mozilla.org/show_bug.cgi?id=264721
(NEW)
Now that Bugzilla has been upgraded to 3.2, which has customizable
statuses, we are in a position to implement this second idea if we choose.
Does that chart given above still represent the workflow we are aiming
for? Or does it need updating for 2008 in some way?
Gerv
Gervase Markham
> Does that chart given above still represent the workflow we are aiming
> for? Or does it need updating for 2008 in some way?
I think a READY state would be very useful, because *as long as we don't
allow people to file directly into it*, it would mean that every bug
there had passed through QA and was in a known good state. This would
allow us to triage the current vast body of NEW bugs and pull out the
ones which are fixable as they stand.
I suggest permitting the following transitions only:
UNCONFIRMED -> READY }
NEW -> READY } - bug has been triaged
ASSIGNED -> READY - assignee decided not to implement
READY -> NEW - assignee decides more QA attention needed
READY -> ASSIGNED - assignee takes it on
READY -> RESOLVED - assignee fixes without going through ASSIGNED
IMO we should not allow:
{Filed} -> READY - because no QA step. People filing bugs to work on
them directly can go straight to ASSIGNED anyway.
REOPENED -> READY - because if it's been reopened, some thought is
needed about what the correct fix is.
RESOLVED etc. -> READY - should go to REOPENED, as now.
Gerv
Axel Hecht
I know that I file tons of bugs, basically round about 10 per new
locale, like a few per each major update, most of which are in READY
state. That doesn't mean that I file them assigned to a particular owner
in a localization team.
Axel
Boris Zbarsky
> {Filed} -> READY - because no QA step. People filing bugs to work on
> them directly can go straight to ASSIGNED anyway.
What about people filing followup bugs that they are not planning to
work on themselves, or generally people filing bugs in areas of their
expertise that they themselves don't plan to work on.
Data: Since Jan 1, 2007, I have filed 387 Core bugs. Of these, 148 are
assigned to me (though not all of them were assigned to me at the time
of filing, I think). If we restrict to DOM and Layout components, the
numbers are 126 and 70 respectively.
I'm pretty sure that those other 56 bugs were READY as filed, though
I've been known to screw up, of course.
I suppose I can live with reloading the bug and changing it to READY by
hand, but if we can avoid it that would be nice.
Things are complicated by the fact that I don't think bugs I file in
Firefox should automatically end up in the READY state....
-Boris
P.S. I use myself as an example here, but similar considerations apply
to anyone who's going to be working on any part of the code and filing
bugs on others who also work on that code.
Michael Connor
> Gervase Markham wrote:
>> {Filed} -> READY - because no QA step. People filing bugs to work on
>> them directly can go straight to ASSIGNED anyway.
>
> What about people filing followup bugs that they are not planning to
> work on themselves, or generally people filing bugs in areas of their
> expertise that they themselves don't plan to work on.
>
> Data: Since Jan 1, 2007, I have filed 387 Core bugs. Of these, 148
> are
> assigned to me (though not all of them were assigned to me at the time
> of filing, I think). If we restrict to DOM and Layout components, the
> numbers are 126 and 70 respectively.
>
> I'm pretty sure that those other 56 bugs were READY as filed, though
> I've been known to screw up, of course.
>
> I suppose I can live with reloading the bug and changing it to READY
> by
> hand, but if we can avoid it that would be nice.
>
> Things are complicated by the fact that I don't think bugs I file in
> Firefox should automatically end up in the READY state....
>
> -Boris
I agree here, there's plenty of times where I will file a bug with all
relevant info. QA doesn't need to waste their time double-checking my
work. Forcing people to jump through hoops isn't useful. The biggest
win of READY is that canconfirm can be given freely without worrying
about bypassing QA. I would probably actually raise the bar for
editbugs once cantriage is effective at doing triage, and only give
editbugs to people who _really_ know what they're doing.
The current bugzilla bug entry form lets you choose status (UNCO, NEW,
ASSIGNED) on filing. I added READY to https://bugzilla-stage-tip.mozilla.org/
as a test, and you can choose READY, or NEW, or ASSIGNED, based on
whatever is appropriate.
-- Mike
Axel Hecht
I'm more freely giving editbugs than we probably would want to to
localization owners, just because that's required to grant reviews and
set keywords and such. I usually add a "use your powers wisely", but
that's just convention.
That just to say that we'll need to take those powers with a grain of
salt, at least as long as they're not restricted to particular
product/modules.
That's partly an edge case, but it might also be an indication of
over-engineering the problem.
Axel
fantasai
I agree with Boris that it should be possible to file a bug as READY.
You probably don't want it to be the default state for anyone, but it
should be possible. E.g. I don't think
https://bugzilla.mozilla.org/show_bug.cgi?id=452345
needs QA review.
NEW -> ASSIGNED should be possible also, btw.
~fantasai
dolphinling
> I think a READY state would be very useful, because *as long as we don't
> allow people to file directly into it*, it would mean that every bug
> there had passed through QA and was in a known good state. This would
> allow us to triage the current vast body of NEW bugs and pull out the
> ones which are fixable as they stand.
What's the definition of "passed through QA and is in a known good state"?
Is it "has pointers to what code needs to change"? Is it "someone with editbugs
verified this, not just someone with canconfirm"? Is it somewhere in the middle?
Also, what about bugs that are well reported and fixable as they stand, but need
a fix/wontfix decision? Are those ready?
--
dolphinling
<http://dolphinling.net/>
Mike Connor
> Gervase Markham wrote:
>
>> I think a READY state would be very useful, because *as long as we don't
>> allow people to file directly into it*, it would mean that every bug
>> there had passed through QA and was in a known good state. This would
>> allow us to triage the current vast body of NEW bugs and pull out the
>> ones which are fixable as they stand.
>>
>
> What's the definition of "passed through QA and is in a known good state"?
>
Did you read the workflow?
http://steelgryphon.com/testcases/bugzilla-workflow-9.png
It is, in a nutshell:
* Not a dupe
* If RFE, has module owner signoff and a functional spec
* Has a testcase attached, if needed
* Is a valid bug
> Is it "has pointers to what code needs to change"? Is it "someone with editbugs
> verified this, not just someone with canconfirm"? Is it somewhere in the middle?
>
More succinctly, it has the right amount of information needed for a
developer to just fix it.
> Also, what about bugs that are well reported and fixable as they stand, but need
> a fix/wontfix decision? Are those ready?
>
Not really. That pretty much falls into the "is an enhancement request"
category. One goal is that everything in READY is actually ready to be
fixed and should be fixed. Everything else needs
planning/discussion/triage. This also makes it easier to point new
people at a sane buglist and not have them risk fixing a bug only to get
r- for doing it wrong or fixing something that should be WONTFIX.
-- Mike
dolphinling
> dolphinling wrote:
>>
>> What's the definition of "passed through QA and is in a known good
>> state"?
>>
>
> Did you read the workflow?
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
Oops, no (well, in the past few years or so...)
> It is, in a nutshell:
>
> * Not a dupe
> * If RFE, has module owner signoff and a functional spec
> * Has a testcase attached, if needed
> * Is a valid bug
>
> More succinctly, it has the right amount of information needed for a
> developer to just fix it.
>
> One goal is that everything in READY is actually ready to be
> fixed and should be fixed.
I would make sure that at least this much info gets to
https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_status and any other
similar/appropriate place. I know I'll want to make sure I don't promote bugs
too quickly.
Another question: What about bugs that clearly aren't READY, but also clearly
need developer attention to proceed? How can we ensure those get the attention
they need?
As an example, let me push one of my bugs:
<https://bugzilla.mozilla.org/show_bug.cgi?id=451985> (Crash at every shutdown
with completely blank stack trace). In the workflow diagram, it seems to have
passed all the steps to get out of NEW, but I doubt it could be fixed without
more interaction between me and someone who knows what they're doing.
If the border between NEW and READY is meant to be a handoff from QA to
developers, I can easily see bugs like this getting lost.
--
dolphinling
<http://dolphinling.net/>
Gervase Markham
> I suppose I can live with reloading the bug and changing it to READY by
> hand, but if we can avoid it that would be nice.
I guess it's a trade-off between making you do that work, and the risk
that bugs start off in the READY state which are not READY, which
damages the triage process.
The principle of "start strict, and loosen later" suggests we should
start by forbidding this and seeing how much of a bind it is in practice.
Another alternative would be Yet Another Group of people who were
permitted to file in READY. We could use inheritance from other groups
more-trusted-than-editbugs to reduce the maintenance burden.
Gerv
Gervase Markham
> What's the definition of "passed through QA and is in a known good state"?
See the workflow :-)
> Also, what about bugs that are well reported and fixable as they stand,
> but need a fix/wontfix decision? Are those ready?
Yes.
Gerv
Martijn
> dolphinling wrote:
>> What's the definition of "passed through QA and is in a known good state"?
>
> See the workflow :-)
What does QA stand for, exactly? Everyone that has canform privileges?
>> Also, what about bugs that are well reported and fixable as they stand,
>> but need a fix/wontfix decision? Are those ready?
>
> Yes.
What's the difference between NEW and READY?
Regards,
Martijn
> Gerv
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Martijn
> dolphinling wrote:
>> Gervase Markham wrote:
>>
>>> I think a READY state would be very useful, because *as long as we don't
>>> allow people to file directly into it*, it would mean that every bug
>>> there had passed through QA and was in a known good state. This would
>>> allow us to triage the current vast body of NEW bugs and pull out the
>>> ones which are fixable as they stand.
>>>
>>
>> What's the definition of "passed through QA and is in a known good state"?
>>
>
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
According to that workflow, a bug should not be marked FIXED if the
fix is also needed on branches.
Afaik, this is not what is happening now at bugzilla.
A bug is marked FIXED as soon as the patch has been checked in on trunk.
Regards,
Martijn
> It is, in a nutshell:
>
> * Not a dupe
> * If RFE, has module owner signoff and a functional spec
> * Has a testcase attached, if needed
> * Is a valid bug
>
>> Is it "has pointers to what code needs to change"? Is it "someone with editbugs
>> verified this, not just someone with canconfirm"? Is it somewhere in the middle?
>>
> More succinctly, it has the right amount of information needed for a
> developer to just fix it.
>
>> Also, what about bugs that are well reported and fixable as they stand, but need
>> a fix/wontfix decision? Are those ready?
>>
> Not really. That pretty much falls into the "is an enhancement request"
> category. One goal is that everything in READY is actually ready to be
> fixed and should be fixed. Everything else needs
> planning/discussion/triage. This also makes it easier to point new
> people at a sane buglist and not have them risk fixing a bug only to get
> r- for doing it wrong or fixing something that should be WONTFIX.
>
> -- Mike
Mike Connor
> On Tue, Sep 2, 2008 at 9:33 AM, Mike Connor <mco...@mozilla.com> wrote:
>
>> dolphinling wrote:
>>
>>>
>>>
>>>> I think a READY state would be very useful, because *as long as we don't
>>>> allow people to file directly into it*, it would mean that every bug
>>>> there had passed through QA and was in a known good state. This would
>>>> allow us to triage the current vast body of NEW bugs and pull out the
>>>> ones which are fixable as they stand.
>>>>
>>>>
>>> What's the definition of "passed through QA and is in a known good state"?
>>>
>>>
>> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
>>
>
> According to that workflow, a bug should not be marked FIXED if the
> fix is also needed on branches.
> Afaik, this is not what is happening now at bugzilla.
> A bug is marked FIXED as soon as the patch has been checked in on trunk.
>
Yeah, that's not quite crisp enough. Ideally we'd have sane fixed-in
options...
I'm going back through this and recreating the Visio diagram so I can
update this and a few other things, as well as a sanity check.
-- Mike
Frédéric Buclin
> I'm more freely giving editbugs than we probably would want to to
> localization owners, just because that's required to grant reviews and
> set keywords and such. I usually add a "use your powers wisely", but
> that's just convention.
>
> That just to say that we'll need to take those powers with a grain of
> salt, at least as long as they're not restricted to particular
> product/modules.
You already can give editbugs+canconfirm on a per-product basis, so that
they don't have such privs in other products.
LpSolit
Mike Connor
that out!)
-- Mike
Joshua Cranmer
> It is, in a nutshell:
>
> * Not a dupe
> * If RFE, has module owner signoff and a functional spec
> * Has a testcase attached, if needed
> * Is a valid bug
This works for actual bugs or RFEs, but not for TODOs in terms of
backend rework. Suppose I'm gutting some unused code somewhere. Should
it be marked NEW or READY before I assign it to myself? I know where to
gut the code, but I don't know what actually gets gutted until I go to
the codebase and see the mess to be cleaned up...
Boris Zbarsky
> What's the difference between NEW and READY?
For layout bugs, say:
NEW: Site doesn't work, works in Fx2, doesn't seem like it's
browser-sniffing on the part of the site, not an obvious dup.
READY: The above, plus a testcase and regression range.
-Boris
Mike Connor
refactor nsIFoo to have methods Bar and Baz, and there's a clear
description of what needs to change, and the module owner has signed off
the plan, then READY. If its "we should do something better with nsIFoo
but there isn't a detailed plan in place, then NEW.
READY means "this bug can be picked up and fixed without a lot of
discussion"
-- Mike
Gervase Markham
> You already can give editbugs+canconfirm on a per-product basis, so that
> they don't have such privs in other products.
Can we? Where is the UI for this?
Again, I'd say that this is process for the sake of it. Unless we've had
specific problems with people abusing editbugs (and I have a standing
open invitation for people to email me if they see any), then
restricting editbugs like this will just result in frustrated
contributors and more "please can I have more permissions" requests.
Gerv
Gervase Markham
> This works for actual bugs or RFEs, but not for TODOs in terms of
> backend rework. Suppose I'm gutting some unused code somewhere. Should
> it be marked NEW or READY before I assign it to myself?
If you want to work on the bug, assign it to yourself, and then it's
ASSIGNED :-) It doesn't have to be in a special state before that.
Process is not a straitjacket.
Or have I missed your point?
Gerv
Gervase Markham
> I'm going back through this and recreating the Visio diagram so I can
> update this and a few other things, as well as a sanity check.
This time, please post the Visio diagram as well as a PNG :-)
<broken-record>
Better yet, save it in a non-proprietary file format... :-P
</broken-record>
Gerv
Joshua Cranmer
What I meant to say is this: before moving into the ASSI stage, would
the bug be in NEW stage or would it be in the READY stage? The
discrepancy comes up because the actual semantics of what is involved
may not be defined until the work has actually commenced.
It feels like READY should be the new NEW (take this bug and work on
it), but the definition of READY being "fully spec'd out" clashes with
some bugs which can't be spec'd until they're worked on.
Mike Connor
> Mike Connor wrote:
>
>> I'm going back through this and recreating the Visio diagram so I can
>> update this and a few other things, as well as a sanity check.
>>
>
> This time, please post the Visio diagram as well as a PNG :-)
>
Yeah, I can do that.
> <broken-record>
> Better yet, save it in a non-proprietary file format... :-P
> </broken-record>
>
Is there a useful non-proprietary file format that's useful?
-- Mike
Gervase Markham
> Is there a useful non-proprietary file format that's useful?
A non-proprietary vector file format? Er, SVG? :-)
If you mean one Visio can save in, I don't know about Visio's
capabilities. OpenOffice.org Draw and Inkscape can both save as SVG or
other open formats. Plus probably anything on this list:
http://en.wikipedia.org/wiki/Category:Free_diagramming_software
Gerv
Frédéric Buclin
> Can we? Where is the UI for this?
Sure you can, since Bugzilla 3.0 (bug 189627). You have to edit group
controls for a product (e.g.
editproducts.cgi?action=editgroupcontrols&product=Firefox ), and from
here you can give local canconfirm, editbugs or editcomponents privs for
the groups you want. Note that there is an OR relationship here, so you
don't need to belong to all groups which have e.g. the canconfirm
checkbox checked to inherit local canconfirm privs. This is also very
useful to let a given group of users to edit the milestones, versions
and components of their product without giving them global
editcomponents privs.
LpSolit
Benjamin Smedberg
ervase Markham wrote:
> Way back in 2005, mconnor made a proposal, later refined, for improving
> the Bugzilla workflow:
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
> https://wiki.mozilla.org/BugzillaWorkflowImprovements
>
> There were two key proposals:
>
> - Make canconfirm able to mark as DUPLICATE and WORKSFORME
> https://bugzilla.mozilla.org/show_bug.cgi?id=314056
> (RESOLVED FIXED as a b.m.o. patch in December 2007)
>
> - Add a new READY state which goes between NEW and ASSIGNED
> https://bugzilla.mozilla.org/show_bug.cgi?id=264721
> (NEW)
>
> Now that Bugzilla has been upgraded to 3.2, which has customizable
> statuses, we are in a position to implement this second idea if we choose.
>
> Does that chart given above still represent the workflow we are aiming
> for? Or does it need updating for 2008 in some way?
Metadata has a cost, and it's not clear to me what problems we're trying to
solve with the READY state. So, for lack of clear benefits, I think that the
READY state is going to be yet another pieces of mostly useless metadata.
I think that the chart that mconnor provided originally is a good diagram
explaining the general life cycle of a bug: this is how we triage and fix
bugs, in a nice graphical outline. But I don't think we need to codify every
flow point with a piece of metadata.
How is the READY state going to improve bug triage or bugfix rates? I don't
think that the ready state provides any better metadata for a *human* than
keywords/flags/whiteboard. So the question really comes down to, are there
*automated* processes which can usefully distinguish between READY and NEW?
What are they?
--BDS
L. David Baron
> - Add a new READY state which goes between NEW and ASSIGNED
> https://bugzilla.mozilla.org/show_bug.cgi?id=264721
> (NEW)
So, if READY means that a bug is actually ready, what's the
difference between NEW and UNCONFIRMED?
I've long wanted a way to move NEW / REOPENED bugs back to
UNCONFIRMED. How would adding that capability compare to adding yet
another state?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Joshua Cranmer
> So, if READY means that a bug is actually ready, what's the
> difference between NEW and UNCONFIRMED?
As I understand it:
UNCO = only the user can see it.
NEW = okay, it's a real bug
READY = okay, now someone just needs to implement it.
> I've long wanted a way to move NEW / REOPENED bugs back to
> UNCONFIRMED. How would adding that capability compare to adding yet
> another state?
+1 on this idea. In the TB world, we have a lot of legacy NEW bugs that
would be UNCO if they were filed today. It also feels suspiciously like
READY was introduced to relieve the strain on the NEW bug counts
(there's this deep, dark feeling in me that someone will be arguing in
another few years about adding a new state after READY if it's
implemented...)
Michael Connor
On 2-Sep-08, at 10:33 AM, L. David Baron wrote:
> On Monday 2008-09-01 17:35 +0100, Gervase Markham wrote:
>> - Add a new READY state which goes between NEW and ASSIGNED
>> https://bugzilla.mozilla.org/show_bug.cgi?id=264721
>> (NEW)
>
> So, if READY means that a bug is actually ready, what's the
> difference between NEW and UNCONFIRMED?
NEW has always been pretty much a mixed bag of stuff ranging from bugs
that someone can actually reproduce to bugs with testcases and
analysis/design specs/etc. I think its overloaded, heavily, as a state.
I think in order to scale triage/QA, we need to make it easier to
split the tasks apart. There's a fairly low bar for reproducing,
obvious dupe checking, etc, and a much higher bar for reducing
testcases, getting more detailed STR, and ensuring that bugs are in
the right place. Having that be expressed as a single step puts too
much load on the relatively small number of people who can effectively
do the latter. If we can cut the incoming bug volume by 50% for those
people, and let them focus on bugs that people can actually reproduce,
its the best possible use of their time. And that first pass triage
is a great way to learn more about Mozilla and to make a contribution
without needing in-depth technical chops or specialized knowledge. If
people like Martijn and Jesse are focused on the best use of their
skills, and we have an army of people filtering out the cruft, I think
we gain a hell of a lot.
To use layout as an example:
UNCO - I have a bug
NEW - Other people can confirm that the behaviour can be reproduced
given the information in the bug, and the bug is not an obvious dupe.
READY - Bug has a testcase and analysis that it is a real bug and
should be fixed.
I think each state is distinct, and differs enough from the others
that overloading either UNCO or NEW means that it isn't immediately
obvious where to focus effort. With three states, you get UNCO ==
general triage, NEW == component QA/analysis, READY == developers
looking for something to fix. I do believe that if we can get each
group working effectively, people like Boris and yourself could spend
more time solving known problems.
> I've long wanted a way to move NEW / REOPENED bugs back to
> UNCONFIRMED. How would adding that capability compare to adding yet
> another state?
I don't think it solves anything like I'm trying to solve here, but
its entirely possible with 3.2 to enable this, FWIW.
-- Mike
Michael Lefevre
> Mike Connor wrote:
>> Is there a useful non-proprietary file format that's useful?
>
> A non-proprietary vector file format? Er, SVG? :-)
Are there any other than SVG?
Visio will save as WMF and EPS, which are both proprietary but
reasonably well supported by other things (including OpenOffice).
Visio's EPS export is rather flaky, but WMF seems to work.
--
Michael
Daniel Veditz
> IMO we should not allow:
>
> REOPENED -> READY - because if it's been reopened, some thought is
> needed about what the correct fix is.
Then why have reopened? Isn't that the state for thinking about what to
do? Otherwise why wouldn't we be reopening the bug into the NEW state
and getting rid of the extra status.
Quite often reopened bugs are immediately READY: the patch may have a
bug, or maybe the fix needs a whole new approach (perf issues, for
example) but that doesn't mean we need to rethink the problem itself.
Simon Paquet
> Sure you can, since Bugzilla 3.0 (bug 189627). You have to edit group
> controls for a product (e.g.
> editproducts.cgi?action=editgroupcontrols&product=Firefox ), and from
> here you can give local canconfirm, editbugs or editcomponents privs for
> the groups you want. Note that there is an OR relationship here, so you
> don't need to belong to all groups which have e.g. the canconfirm
> checkbox checked to inherit local canconfirm privs. This is also very
> useful to let a given group of users to edit the milestones, versions
> and components of their product without giving them global
> editcomponents privs.
Interesting. I didn't know that. I just applied for getting my
privileges
upgraded for the Calendar product :)
Simon
--
Thunderbird/Calendar Localization (L10n) Coordinator
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Gervase Markham
> Gervase Markham a écrit :
>> Can we? Where is the UI for this?
>
> Sure you can, since Bugzilla 3.0 (bug 189627). You have to edit group
> controls for a product (e.g.
> editproducts.cgi?action=editgroupcontrols&product=Firefox ), and from
> here you can give local canconfirm, editbugs or editcomponents privs for
> the groups you want.
Ah. So in order to have a group which has editbugs in e.g. Calendar and
not anywhere else, you'd need to create a group called, say,
"editbugs-calendar", then check the relevant checkbox on that screen?
This is a different model to enabling editbugs for a particular user on
a per-product basis. I'm not sure we could use the above model easily,
even if we wanted to, because it would require an editbugs-* group for
each sub-group of Bugzilla products we wanted to give people editbugs for.
I'm very much in favour of using social controls for this until/unless
they are shown not to work.
Gerv
Gervase Markham
> It feels like READY should be the new NEW (take this bug and work on
> it), but the definition of READY being "fully spec'd out" clashes with
> some bugs which can't be spec'd until they're worked on.
READY is "ready to be worked on". That will inevitably mean slightly
different things for different bugs.
Gerv
Frédéric Buclin
> Ah. So in order to have a group which has editbugs in e.g. Calendar and
> not anywhere else, you'd need to create a group called, say,
> "editbugs-calendar", then check the relevant checkbox on that screen?
Correct. But you probably don't need tens of additional groups. Not
every product/project needs such fine grained privs. It seems the reason
Axel gives editbugs privs to some l10n people is to let them review
patches and set keywords accordingly. So this would be one example where
this solution would be appropriate. This doesn't mean other projects
need this.
LpSolit
Axel Hecht
I don't think we need this for l10n either, honestly. So far, I haven't
heard any complaints about localizers running wild in triaging other
components and making a mess. Not that I heard any reports from them
cleaning up of the existing mess either, sadly ;-)
Axel
Martijn
Ah, sorry, I should have read
https://bugzilla.mozilla.org/show_bug.cgi?id=264721 then I would have
known it.
But the way you put it, this could be done automatically by bugzilla.
I was afraid that Mozilla QA had to go through all the bugs to mark
them READY if they were ready.
Regards,
Martijn
> -Boris
Gervase Markham
> I was afraid that Mozilla QA had to go through all the bugs to mark
> them READY if they were ready.
I think it is the idea that bugs will only enter the READY state
manually. Having them enter it automatically would lose a lot of the
benefit.
That's not to say that we are landing a big job on QA "check every bug
in the database to see if it's ready, and if so, switch it to READY".
But it would become part of the normal processes to check the things on
the flowchart and mark the bug you are dealing with appropriately.
Gerv
Gervase Markham
> Gervase Markham wrote:
>> IMO we should not allow:
>>
>> REOPENED -> READY - because if it's been reopened, some thought is
>> needed about what the correct fix is.
>
> Then why have reopened? Isn't that the state for thinking about what to
> do? Otherwise why wouldn't we be reopening the bug into the NEW state
> and getting rid of the extra status.
Good point. OK, so REOPENED -> READY makes sense.
Gerv
Gervase Markham
> +1 on this idea. In the TB world, we have a lot of legacy NEW bugs that
> would be UNCO if they were filed today. It also feels suspiciously like
> READY was introduced to relieve the strain on the NEW bug counts
> (there's this deep, dark feeling in me that someone will be arguing in
> another few years about adding a new state after READY if it's
> implemented...)
This is why I think it should either be impossible to file as READY, or
(at the very least) should not be anyone's default.
If every bug which moves into READY does so by explicit triager choice,
we are much less likely to end up in that place.
Gerv