On 03/12/2022 13.20, Michał Górny wrote:
On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote:
On 03/12/2022 12.34, Michał Górny wrote:
On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote:
On 03/12/2022 08.09, Michał Górny wrote:
Hi,
I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
states with a simple NEW state. Why?
1. Only a handful of developers actually uses these two statuses
in a meaningful way.
2. Some users are confused and demotivated by having their bugs stay
UNCONFIRMED for a long time.
While I do not strictly oppose that change, I like the UNCONFIRMED /
CONFIRMED states.
I don't know how 1. is an argument for removing it. Quite the contrary,
the statement itself says that the feature is used. Furthermore, it is
not my observation that only a handful of developers use it. Most open
bugs are in the CONF state [1], so I would conclude that most use the
feature. Of course, that depends on your definition of "used in a
meaningful way". For me, CONFIRMED was always about someone, usually a
-dev, acknowledging that the bug reports a valid issue that needs to be
addressed (either by Gentoo or upstream). Is that using it in a
meaningful way?
Does that imply that bugs that are UNCONFIRMED are not worth our effort?
No, not all. Could you elaborate how you derive this implication?
I had always assumed that UNCONFIRMED means that nobody (as in, no dev)
looked at the issue report and vetted its validity. Nothing more,
nothing less.
I'm trying to understand what actual value this has. Unless it's data
for the sake of having data.
That is a valid concern.
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.
A similar case can be made for IN_PROGRESS. However, I see how one could
argue that IN_PROGRESS provides more value than UNCONFIRMED / CONFIRMED.
As I said, I do not strictly oppose this change. But since this is a
RFC, I commented. :)
Maybe it is just me being used to bug transition states being
NEW / UNCONFIRMED → CONFIRMED → IN_PROGRESS → CLOSED
(with intermediate states being optional)
- Flow