s/labe/Elbe/ or s/labe/label/ depending on which one you meant On a Wednesday in 2021, Peter Krempa wrote:

Hi,

from time to time when I try to go through upstream issues I always feel that the labels we have are suboptimal and don't always allow to track the current state of the issue.

Recently I've had a look at the qemu issues and found what I was lacking.

Specifically I'm lacking the 'workflow' class of labels they use.

I propose we adopt the following changes:

1) Convert the existing 'bug', 'enhancement', 'support', and 'discussion' labels into a set of scoped labels (again inspiration taken from qemu):

kind::bug kind::enhancement kind::support kind::discussion kind::documentation

This is mostly as the above kinds are mutually exclusive.

Makes sense. From the group labels: https://gitlab.com/groups/libvirt/-/labels this leaves: bitesizedtask this refers to the scope/difficulty of the issue I think it's mutually exclusive with gsoc::ideas and gsod:ideas, so we could replace those with: scope::Bite Sized scope::Summer of Code ci refers to the area/subcomponent of the project Could be mutex with driver: critical I also don't think we need this.

2) Introduce the workflow label similarly to what qemu uses:

workflow::Confirmed/Triaged (<- confirmed for bugs, triaged for enhancements) workflow::Needs Info (replaces "needinfo") workflow::In progress (replaces "Doing")

I'd also potentially like to have a 'Unconfirmed' state for when the bug has enough info, but it's unknown why it's happening.

I want to specifically avoid the ambiguous "Triaged" when used on it's own.

QEMU's workflow::Triaged label is described as: Issue has been triaged and given a topic label. This seems pointless - you should be able to find that out from there being labels on the issue. Confirmed makes sense for bugs that were reproduced. For enhancements, I don't see a need to have a workflow label, unless the idea is that every issue will have a workflow label.

3) Convert host-* labels into a scoped label. Hosts are usually mutually exclusive

Agreed. And if we're moving away from lowercase labels, we can spell them as Linux, FreeBSD and whatever the latest preferred spelling of macOS is.

4) Convert driver-* into scoped labels. Usually issues are not exceeding these boundaries

We also have: api cpumodel daemons security-apparmor security-selinux virsh xml To some extent these are mutually exclusive with drivers (and also 'ci') so we could scope them together. Something like: area::ci area::qemu area::selinux area::virsh I'm not sure whether there is any value in having both 'qemu' and 'selinux' labels on a bug affecting QEMU driver's use of SELinux. There's definitely no point in labeling a new API for QEMU driver with 'api' 'qemu' 'virsh' 'xml'. The usage of the 'xml' label is also confusing - we have it on an issue requesting more virsh completions as well as QEMU feature requests. If we keep it I'd say it should be only for issues that are exclusively in the formatter/parser.

5) Remove the following unused or ambiguous labels:

- critical - incident - Doing - To Do - gsoc::20* (all seem to be unused)

I'm willing to go ahead and re-triage open stuff if nobody objects to the above changes.

Let me know if I can help. Jano

On 12/8/21 16:34, Peter Krempa wrote:

Hi,

Should we also have a label for regression? Either if an issue needs to be re-opened or if filed new and captures something that used to work. On the other hand, it can be simulated by setting bug + critical labels. Michal