Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs

[Mike Pagano]

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

The kernel may be a special case, but personally I use unconfirmed and don't 'confirm' it until it's determined if it's a real kernel bug.
Sometimes the kernel is the messenger and not the cause.  But this is not a documented process and only exists in my head.

Whatever the consensus is I can live with.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead
E-Mail     : mpagano@g.o
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index