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 : mpag...@gentoo.org
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
