9:34 a.m.
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.
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.
3) Convert host-* labels into a scoped label. Hosts are usually mutually
exclusive
4) Convert driver-* into scoped labels. Usually issues are not exceeding
these boundaries
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.
2:47 a.m.
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
5:14 a.m.
On Wed, Dec 08, 2021 at 04:34:27PM +0100, 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.
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.
3) Convert host-* labels into a scoped label. Hosts are usually mutually
exclusive
This is not desirable, we can easily hauve issues that
affect both FreBSD and macOS at the same time.
4) Convert driver-* into scoped labels. Usually issues are not
exceeding
these boundaries
Again, this is not desirable, as I consider those labels to
mean that it /affects/ users of that driver, rather than it
being in code only related to that driver. IOW, if there is
a cgroups bug it is relevant to want to put a label of qemu,
lxc and ch.
5) Remove the following unused or ambiguous labels:
- critical
I think this is useful as a way to mark an issue as very
important.
- incident
This feels redundant since we're not providing production
support for some service.
- Doing
- To Do
'To do' is really just anothuer work for 'enhancement'
- gsoc::20* (all seem to be unused)
The intent of gsoc labels is that we'll use those to track
gsoc ideas instead of the wiki. When someone starts working
on a particular project, it'll get tagged with the year.
I was intending to copy over historical content from the
wiki prior to deleting the wiki
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
1078
days inactive
1080
days old
3 comments
4 participants
participants (4)
-
Daniel P. Berrangé -
Ján Tomko -
Michal Prívozník -
Peter Krempa