| 1 |
On 17 June 2016 at 01:52, Joshua Kinard <kumba@g.o> wrote: |
| 2 |
> because |
| 3 |
> sometimes, issues can get reported that are really obscure and, for example, |
| 4 |
> tied to a particular hardware configuration, thus cannot be easily and |
| 5 |
> independently confirmed |
| 6 |
|
| 7 |
|
| 8 |
Isn't that why "RESOLVED: Need Info" exists? |
| 9 |
|
| 10 |
Or is "CONFIRMED" supposed to imply "I can replicate this", as opposed |
| 11 |
to the description bugzilla uses: "Determined to be present". ( |
| 12 |
https://bugzilla.readthedocs.io/en/5.0/_images/bzLifecycle.png ) |
| 13 |
|
| 14 |
Our current doc only describes CONFIRMED vs UNCONFIRMED in terms of |
| 15 |
"valid" and its predominantly used as a "Can't triage" : |
| 16 |
|
| 17 |
> UNCONFIRMED: This bug has recently been added to the database.| |
| 18 |
> Nobody has confirmed that this bug is valid. |
| 19 |
> Users who have the "canconfirm" permission set may confirm this bug, changing its state to CONFIRMED. |
| 20 |
> Or, it may be directly resolved and marked RESOLVED. |
| 21 |
|
| 22 |
> CONFIRMED: This bug is valid and has recently been filed. |
| 23 |
> Bugs in this state become IN_PROGRESS when somebody is working on them, or become resolved and marked RESOLVED. |
| 24 |
|
| 25 |
-- |
| 26 |
Kent |
| 27 |
|
| 28 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives
