On 3 Dec 2022, at 07:09, Michał Górny <mgorny@gentoo.org> 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.

Yes please. We can always revisit if an actual issue arises wrt needing
to show things as "CONFIRMED", but I've not seen any usage of
UNCONFIRMED vs CONFIRMED in a way that matters other than
helping out confused users.

While at it, I'd love to talk about UPSTREAM [0] , but that's for
another day :)

[0] https://archives.gentoo.org/gentoo-project/message/a16cedda9f4b3f8d88e3291d5d0201da

best.
sam


-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY4sBk18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kFsiAQCv2pf5QR5vsc5ms2iKjXy3N+oL6lItd3XOxKRhZiYXDgEAua89k8IT9MQi eBPsJg/QO6qtOU4Z6f+aM96SRRbOrgE=
=0Kea
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 03 Dec 2022, Michał Górny wrote:

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.

Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY-COMMUNITY,
and leave CONFIRMED alone? :)

However, I suspect that the real problem isn't the status label, but
when there's no action on the bug (sometimes for months or years).

Ulrich

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmOLC0sPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4u7xAIALlXYRysPhUJD8amyICakI1SkOoA6X8nIr4R nYqMpG7PFkuBWX2pB5lJmT/hmeB+Sttf6h7QnZtf/ruX9Txd7mXRNGtBD9QMXOkY 2jxPrmKO9iAyuCA6KBo4pU739zHQc+iI+pZhqZUqukT/sPEvkRljOjYGqkL+ZaTy Ols9SJWtq/qqqkfIFzj54RcHGkhhmXvZNNQb7tzxyCz3W7BtlZTk0weW4bUQpA+a J3Vzi5BW749xUYVG3wQIdvriN27kQr8BpXQ+8M8xa0WbCk7tE0+NzNwvwls6tICy vPvFD/kngnYNMXuonhTMqE7gtAEYS+4TqaDIXvmaNu0DvzSQqyo=wtsD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2022-12-03 at 09:39 +0100, Ulrich Mueller wrote:

On Sat, 03 Dec 2022, Michał Górny wrote:

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.

Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY-
COMMUNITY,

Done.

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------J61lqc2AtM2PtZjd89BDSgeU
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMTIvMy8yMiAxMDo1MywgTWljaGHFgiBHw7Nybnkgd3JvdGU6DQo+IE9uIFNhdCwgMjAy Mi0xMi0wMyBhdCAwOTozOSArMDEwMCwgVWxyaWNoIE11ZWxsZXIgd3JvdGU6DQo+PiBUaGVu IHJlbmFtZSBVTkNPTkZJUk1FRCB0byBORVctV0lUSC1TVUdBUi1PTi1UT1AtV0UtQVJFLUEt SEFQUFktDQo+PiBDT01NVU5JVFksDQo+IA0KPiBEb25lLg0KPiANCg0KSSBkbyBzZWFyY2gg Zm9yIGJ1Z3MgdXNpbmcgcHlidWd6ICBhbmQgZ3JlM3AgZm9yIENPTkZJUk1FRCBhbmQgZG8g d29uZGVyIA0KaWYvd2hlbiBJIHNoYWxsIGdyZXAgZm9yIE5FVyB0b28gPw0KDQotLSANClRv cmFsZg0KUEdQIDIzMjE3REE3IDlCODg4RjQ1DQoNCg==

--------------J61lqc2AtM2PtZjd89BDSgeU--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEE4Aq096H1MGPqWQN3byNRLEwPvR0FAmOLIDwFAwAAAAAACgkQbyNRLEwPvR2K qhAArUYWFV32KDheTE3nDkwVc+R4ivBoa2g4Qttik8MJNmpkNQm/qxRT9NWmksFQIkxZE2E/XkZn 9GoiCsJj1I5MI4/SiGyTgO0wCwLprYUoINkg8Tj1gZsW8LaNy3dZs2DzdMZ4kHkgNKM/yU83c/a8 eOnkdw3ZT9yPfmWXuG9g80YmCA60+BmIdeVc7VKbSjsIkQuBdZm2OI6JU83HePVc5hGjFTQTad1H UKrLXyU1IWdOTqEl/SFG8jxoUnuRfxZFlIMlMPO+OHfa60ov1Rt8qH4pNED53mGE3t2eV4CrM8rY Jnb9Bh+gU/JcW9CkRCTlxjyJkNfspeHXOHD61n4275QmNYBl7UoTTG31GMfKM0cdFYE2bvsfx178 z9TQQ3QedH3X2DuXmKQgBrb88XygFbotp8tX0BquIQeQ36QAn5oYUvyYyVrruPIujPTUQUma92N4 +h/3ebfIkiLW98KUxH8abNBVoumgQ7/yvQ0he/FFxRjBev/gPbL87UFRS8TiIpOTuCUkx4QDpEpy SyDBbFTBUaI4wbJ2XGBBDCCsxbrYRgvLf1qVDKFPlcls+RXZS1IF4sfyfskcEpFhME7VuA6JzBKf VMcU/55igPrAnqO9lLrTN9LqxvKw+mALczJsnqI2sPhZEE/nySIdM8tH4PrA3WB6mMCElEdBoiSR +CM=
=+j+W
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 03 Dec 2022, Michał Górny wrote:

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.

Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY-
COMMUNITY,

Done.

Seriously, we had UNCONFIRMED, NEW, and ASSIGNED before. The default
status used to be NEW, but with "expert" reporting users could
explicitly assign the status to UNCONFIRMED.

Some people found that not satisfactory, so NEW and ASSIGNED were
replaced by CONFIRMED and IN_PROGRESS. (We also had status REOPENED
which was removed with the same change.) Unfortunately, I cannot find
the old discussion, but [1] suggests that the change took place in 2011
or before.

The Bugzilla Guide [2] still has the old wording:

| • UNCONFIRMED - You're generally not going to see this too often.
| This means that a bug reporter has opened a bug using the advanced
| method and is uncertain their bug is an actual bug.
| • NEW - Bugs that are first opened are considered new.

Tracing the history of that text, it was the same in 2005 [3], and seems
to originate from [4].

A previous discussion about this topic (started by you :) can be found
in [5], BTW.

Ulrich

[1] https://bugs.gentoo.org/391203#c1
[2] https://wiki.gentoo.org/wiki/Bugzilla/Guide#Working_with_a_bug
[3] https://gitweb.gentoo.org/archive/proj/gentoo.git/commit/xml/htdocs/doc/en/bugzilla-howto.xml?id=6947795f3817a6779a81d768e9a5a07380d56aa4
[4] https://bugs.gentoo.org/97274
[5] https://archives.gentoo.org/gentoo-dev/message/b24ea134d3555cd25560090cf4a87657

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmOLN4APHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uLLkH/RMMwWALT5wGFuM1NHAu036KqnKeFsSGKWJS 3Eglibq6WZ5Outd2qlq15Eko+3g64I4TEfBr8CuLsfrveYDNY5fYf1+jglZGbZUN N1mHBVmvWR1aQUuaCFxOobrlAx5N24fGasejCzzNPJG20E5VZEAfRJjzrPTVFBtU pN0eIzGKooMvkkumEhLhsItJJtb5nuTgdbOlQUQEoCdpwuaGQaaO7hl/93kobQYz XODxELphgLVf3DEff3OGtfLdREIyyj5JpcOxHFhq/RRHcNCDSbDQTW22P8qaI5Jz XekXr5s8auw5mp/8iPnN07EIY1LIPidZR1rxz3t32lXNeY9sQr0=wYp/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 03 Dec 2022, Ulrich Mueller wrote:

Some people found that not satisfactory, so NEW and ASSIGNED were
replaced by CONFIRMED and IN_PROGRESS. (We also had status REOPENED
which was removed with the same change.) Unfortunately, I cannot find
the old discussion, but [1] suggests that the change took place in 2011
or before.

In 2011, actually. Discussion is here: https://archives.gentoo.org/gentoo-dev/message/a22baae8830ca806684da98ce7698206

"Right now, it seems logical to use UNCONFIRMED for the new bugs and let
devs (re-)confirm them as necessary.
I think it might be even a good idea to limit the possibility of setting 'CONFIRMED' to devs. Otherwise, I see users bumping each of their bugs
to 'CONFIRMED' immediately." https://archives.gentoo.org/gentoo-dev/message/33e6f39fbfafe95c18c563b12c61d9f0

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmOLPakPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4u2LsIAJaz+wlYTTjQT6piOhMeugA56lxDSJw4G6h4 0fbZG6/t4TGql+Hr4lTvzNOj3cx/A3oUQs6bzJi3nscKTl8jC+8ipj1hlmcZLMQy EoB39MPh+nNwZd/CrtY5+6STcoRC2/366r0j1clWL1wvm74cqHsuQOfGlajkF5tE gRU0IVZLPHb/E/bPfGLNQkrYq/VhHd6JdtiZq2G/j3v0x6bCxk87CbGkKprshrED 1PceiikSrlqO0EkAXvvL+nwio+eC/ut0LEHPp0hAL5ftknEWjVjrhAM/xmTdZ67z UIH4ME17oXgF7PNIo/WELXj1N5YEs8GtGX8OMHVCWCjo8PnVDEg=
=rPQg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

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.

As someone who is very active on bugzilla I think the users are happy about
- real activity and
- polite, precise and clear answers


Renaming tags will rather confuse.
Yes, some tickets are open for long times (this is not a Gentoo-only
problem)
We should not hide this with Newspeak.

I suggest to keep it as it is, because sometimes it makes sense to
confirm a bug.

Are not demotivated, because of the name of the tag.

They are demotivated, if
- bugs remain open/unanswered for long time
- they are told "my dev time is too expensive for your problems" in an
impolite way

--
Best,
Jonas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 3, 2022 at 2:09 AM Michał Górny <mgorny@gentoo.org> 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.

I think I could be counted among the devs who at least try to use the
two statuses. If I stumble upon bugs that I have run into myself, I
will flip them from UNCONFIRMED to CONFIRMED. On the opposite end, I occasionally downgrade bugs from CONFIRMED to UNCONFIRMED if they are particularly strange looking and were filed by a script (tinderbox).

Anyway, if you decide to make the change, please ensure that it
doesn't generate a bunch of pointless bugmail. I have noticed that
some devs will replace obsolete values in Product/Component without
making any other meaningful changes to the bug. Let's avoid that
situation if possible here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)