How to mark or search for confirmed bugs?

[AaronBallman]

Bugzilla had a useful feature where bugs could be marked as confirmed when someone triaged the bug. This allowed people to quickly spot bugs that someone had already validated and was a quite useful feature. Somehow, GitHub doesn't seem to have a dedicated way to do the same thing.

Can we get a new label named confirmed or something along those lines so that we can mark bugs after triaging them? Can we have that label applied to all bugs from Bugzilla that were in the confirmed state so we don't lose all that valuable information?

[llvmbot]

@llvm/issue-subscribers-infrastructure

[EugeneZelenko]

You could create label yourself. I did so several times :-) Of course, it'll be reasonable to agree on its name.

[AaronBallman]

Oh, I didn't know we could create our own labels (that sounds like we're about to be inundated with confusing one-use labels)! But yeah, I was thinking we should probably agree on how we want to triage bugs (like, is the label the "correct" way to go? I don't know.)

https://llvm.org/docs/BugLifeCycle.html#triaging-bugs is no longer really helpful and should probably be updated.

[Quuxplusone]

Right now there is a label ironically titled "new issue", which is bot-applied to every issue within a day or two of its being created — and then removed... at some point? The workflow goes "issue without labels -> issue labeled 'new issue' -> issue without labels".

I agree that

• there should be a label "confirmed";
• the label "new issue" should go away;
• the workflow should go "issue without labels -> issue labeled 'confirmed'."

I personally do have the power to script the addition of "confirmed" to all issues that were in the everconfirmed=1 state on Bugzilla. But I don't have the power to remove the "new issue" bot, because I don't know where it lives.

[asl]

Right now there is a label ironically titled "new issue", which is bot-applied to every issue within a day or two of its being created

The label is created by bot immediately after the issue creation modulo usual github action queue delay if no labels were assigned by the author

and then removed... at some point?

Usually it is removed by whoever assigned a proper label. Sometimes - not.

Labelling of new issues was explicitly requested previously, so it should not be removed

[EugeneZelenko]

I did so only when encountered multiple issues occurrences like clang-cl or compiler-rt:msan.

I doubt that new issue label have too much sense. Absence of label as good as new issue label. And often people forget to remove new label after adding relevant ones or even after closing issues.

[asl]

https://llvm.org/docs/BugLifeCycle.html#triaging-bugs is no longer really helpful and should probably be updated.

Looks like a subtask for #52606

[asl]

I doubt that new issue label have too much sense. Absence of label as good as new issue label. And often people forget to remove new label after adding relevant ones or even after closing issues.

The same bot could listen for relabelling events and remove "new issue" label if any labels were assigned.

[Quuxplusone]

The same bot could listen for relabelling events and remove "new issue" label if any labels were assigned.

Yes, but that would just create two "noise" events in the timeline. I suggest that if #53299 remains open for a week and the original-asker-for the "new issue" bot has not stepped forward to explain why the bot is a good idea, we should just kill off the "new issue" bot, and remove the "new issue" label from all existing open and closed issues.

(Actually, no open issue has gained a "new issue" label since 5 days ago, so maybe the bot is already dead... but I see it applying the label to closed issues as recently as 10 hours ago, so I dunno what the deal is. Anyway, I think we should assume the bot is alive until someone who owns it tells us it's dead.)

Meanwhile, regardless of the fate of "new issue", there's nothing obviously blocking us from adding the "confirmed" label — to be mechanically applied to all everconfirmed Bugzilla issues, and then manually applied in the traditional way from there on out. Ideally that would be done by @asl using the existing @llvmbot account, but FWIW, I could do it from my own account easily enough.

[asl]

Yes, but that would just create two "noise" events in the timeline. I suggest that if #53299 remains open for a week and the original-asker-for the "new issue" bot has not stepped forward to explain why the bot is a good idea, we should just kill off the "new issue" bot, and remove the "new issue" label from all existing open and closed issues.

Feel free to reopen #52614 and discuss there

Actually, no open issue has gained a "new issue" label since 5 days ago, so maybe the bot is already dead...

You are not quite right. The reason for this is simple - excellent work of @EugeneZelenko and others to triage and label new issues. You can easily check by yourself any recently opened issue - there were labelling events in the timeline (e.g. #53295).

[AaronBallman]

Meanwhile, regardless of the fate of "new issue", there's nothing obviously blocking us from adding the "confirmed" label — to be mechanically applied to all everconfirmed Bugzilla issues, and then manually applied in the traditional way from there on out. Ideally that would be done by @asl using the existing @llvmbot account, but FWIW, I could do it from my own account easily enough.

Do we think there's value to tagging any of the resolved statuses as well? (INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME, MOVED). I'm less opinionated on that information, but some of it is quite useful (like WONTFIX clearly says we considered the bug and aren't fixing it, while WORKSFORME clearly says we can't reproduce but the bug may still be valid).

[asl]

Do we think there's value to tagging any of the resolved statuses as well? (INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME, MOVED). I'm less opinionated on that information, but some of it is quite useful (like WONTFIX clearly says we considered the bug and aren't fixing it, while WORKSFORME clearly says we can't reproduce but the bug may still be valid).

DUPLICATE was migrated to "duplicate" label. Note sure about the usefulness of other statuses.