[llvm-bugs] [Bug 39482] test how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our bugzilla

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39482

Kristof Beyls <kristof.beyls at arm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|test                        |test how the
                   |                            |"NEW"/"UNCONFIRMED"/"CONFIR
                   |                            |MED" states work in our
                   |                            |bugzilla
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Kristof Beyls <kristof.beyls at arm.com> ---
I was testing how the "NEW"/"UNCONFIRMED"/"CONFIRMED" states work in our
bugzilla when enabling the builtin "product uses CONFIRMED/UNCONFIRMED" feature
in bugzilla.

The result was that I concluded it wasn't very usable for us.
Let me repeat here what I said on a related LLVM-dev mail thread on this:
"""
It seems that bugzilla by-default will put bugs in the “CONFIRMED” state when
creating new bugs, if the reporter has “can-confirm” rights. I believe our de
facto policy is for everyone with an account to be able to confirm bugs. Also,
you need an account to be able to report a bug. The result is that all new bugs
by default will go to status “CONFIRMED”, unless the reporter carefully
remembers to change the default and select “UNCONFIRMED”. (Also see
https://bugzilla.mozilla.org/show_bug.cgi?id=915682 which suggests this
behaviour is not configurable).

Unless that can be solved, I fear that many bugs will be reported with the
default “CONFIRMED” status even though they aren’t triaged yet. I believe that
is worse than the current default “NEW” state.

The only work around for this behaviour where we still get a “to be triaged”
state I can think of at the moment is to introduce a custom “CONFIRMED” status,
not using bugzilla’s built-in special “UNCONFIRMED” support and have a flow
that would allow something like:

NEW -> CONFIRMED -> ASSIGNED -> RESOLVED -> …

The advantage is we’d have separate states to represent “this bug was raised”
(NEW) vs “this bug was triaged & confirmed” (CONFIRMED).
The disadvantage is that we’ll start deviating from the default bugzilla
workflows.
"""


Since then, we've indeed implemented a custom CONFIRMED state, not using
bugzilla's limited built-in support for it.

Conclusion: this test bug can be resolved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181109/77bf78b8/attachment.html>