| 1 |
On 03/12/2022 14.50, Michał Górny wrote: |
| 2 |
> On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote: |
| 3 |
>> I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and |
| 4 |
>> other (affected) persons, to decide if they need to "chase" the issue's |
| 5 |
>> assigned entity. |
| 6 |
>> |
| 7 |
>> Assume looking at the open bugs list of a developer. If the developer |
| 8 |
>> has old bugs in UNCONFIRMED state, you may want to issue a friendly |
| 9 |
>> ping. Sure, strictly speaking, this would require all bugs to drop back |
| 10 |
>> to UNCONFIMRED when the bug assignee changes. But even without such an |
| 11 |
>> implicit mechanism, those two states provide some value. |
| 12 |
> |
| 13 |
> I don't understand how UNCONFIRMED/CONFIRMED makes any difference here. |
| 14 |
> If I file a bug against some package, it is CONFIRMED by default. |
| 15 |
> If an unprivileged user files it, it's UNCONFIRMED. In both cases |
| 16 |
> the assignee didn't do anything. |
| 17 |
|
| 18 |
The assignee not doing anything keeps the bug UNCONFIRMED if it is |
| 19 |
filled by an unprivileged user. That makes the bug distinguishable from |
| 20 |
a bug that got "verified" by the assignee. |
| 21 |
|
| 22 |
Yes, if *you* (as dev) fill a bug, then it is implicitly CONFIRMED |
| 23 |
(whether or not that is sensible is a different discussion). I do not |
| 24 |
see how this would invalidate my case, though. |
| 25 |
|
| 26 |
- Flow |
Archives