[RFC] GitLab issue tracker labeling process: arch/target, os, and accel labels

[John Snow]

Hi, I'd like to work out our collective preferences for how we triage 
issues that concern the execution environment; namely the arch (now 
"target", os, and accel labels.

If you're CC'd on this mail, you're either listed as a TCG maintainer, a 
target maintainer, or have been heavily involved in the GitLab issue 
tracker migration process. You might care about how we triage and file 
these issues.

I'm sending the mail because I've been (so far) responsible for a lot of 
the labeling as we move over from Launchpad. I'll need to change my 
process to accommodate what our maintainers want to see. (And to 
encourage others to join in on the triage process.)

As of right now, there's no formal process or document for how we use 
any of the labels -- Thomas and I had been only informally collaborating 
in our usage of them as we migrated from Launchpad. Thomas has a script 
he uses to move the bugs, so I usually don't edit these labels until I 
give him a heads up so I don't break his script.

Let's discuss what changes we need to make and collaborate on when and 
how we'll make them.


# Accel

Currently "accel: XXX", for HAX, HVF, KVM, TCG, WHPX and Xen.

https://gitlab.com/qemu-project/qemu/-/labels?subscribed=&search=accel%3A

Multiple accel labels can be applied to an issue, not just one. The 
intent was to allow for issues that may impact multiple accelerators, 
though that case may be rare.

I think these are reasonably straightforward and unambiguous, though for 
some qemu-system reports it's not always evident which accelerator 
applies right away without more info. The accel tag is often omitted 
because of this uncertainty.

I'd like to keep the mapping here 1:1 against ACCEL_CLASS_NAME if I can. 
It makes the mapping from CLI to accel tag fairly straightforward.

We technically lack a "qtest" accel tag for that parity. It could be 
added, but it's likely not actually useful versus the "tests" label. 
It's not really a user-facing accelerator.

I see we also have a new "nvmm" accelerator, too, which should now be 
added here.

RTH raises the issue of the "TCI" subsystem of TCG, which is not a full 
accelerator in its own right, but (I think) a special case of TCG. If I 
keep the 1:1 mapping to ACCEL_CLASS_NAME, "accel: TCI" is inappropriate.

Some suggestions:
- "TCI" by itself, simple enough.
- "TCG-TCI" or "TCG: TCI" or "TCG/TCI" or similar, so that it shows up 
in label search when you search for 'tcg'.
- "accel: TCG:TCI". Similar to above but uses the "accel:" prefix too.

My only concern here is completeness of the label: this one seems like 
it's at particular risk of being forgotten or lost. It works perfectly 
well as an organizational bucket for people working on TCI, but I wonder 
if it will work well as an "issue inbox". Intended use begins to matter 
here. Your thoughts, Stefan?


# OS

Currently "os: XXX" for BSD, Linux, Windows, and macOS.

https://gitlab.com/qemu-project/qemu/-/labels?subscribed=&search=os%3A

Multiple OS labels can be applied to an issue.

Originally, we kept this label somewhat vague and have been using it to 
identify both the host AND guest involved with an issue.

Stefan Weil has requested that we refactor this to separate the concerns 
so that he can identify issues where Windows is the host without wading 
through numerous reports where Windows is merely the guest. Reasonable 
request.

Shall we split it into "host: XXX" and "guest: XXX" for {BSD, Linux, 
Windows, macOS}?

This isn't too hard to do at initial triage time, but we'll need to sift 
through the bugs we've labeled so far and re-label them. Help on this 
would be appreciated. I would prefer we create a *new* set of labels and 
then draw down on the old labels instead of just renaming them. That 
way, the old label can be used as a re-triage queue.


# arch/target

Currently "target: XXX" for alpha, arm, avr, cris, hexagon, hppa, i386, 
m68k, microblaze, mips, nios2, openrisc, ppc, riscv, rx, s390x, sh4, 
sparc, tricore, xtensa.

https://gitlab.com/qemu-project/qemu/-/labels?subscribed=&search=target%3A

The names map 1:1 to the directories in target/.
The names in [square brackets] in the label descriptions correspond 1:1 
with the SysEmuTarget QAPI enum defined in qapi/machine.json.

Multiple target labels can be applied to an issue. Originally, this was 
named "arch", so this was to allow multiple architectures to be 
specified to cover the host/guest environment. If we disentangle this, 
we may still want to allow multiple labels to cover bugs that might 
affect multiple targets, though that case might be rare.

Recently, we renamed this from "arch: XXX" to "target: XXX", though the 
label had been being used for both the host and guest architecture, so 
this will need to be re-audited to remove cases where the label had been 
applied for the host architecture.

We probably want to keep a set of labels that apply to the host 
architecture. These are useful for build failures, environment setup 
issues, or just documenting the exact environment on which an issue was 
observed.

We won't likely require the full set of targets to be duplicated for 
this purpose: possibly just the most common ones. I assume those are:

arm, i386, ppc, s390x

How should we tag those? "host-arch: XXX"?

What I would like to avoid is creating labels like "host: windows-i386" 
where the cross matrix of ({host,guest} X OS x ARCH) starts to require 
ever-increasing specificity of initial triage labels and may increase 
the risk of overly-specified bugs going unnoticed. Maybe my concern is 
unfounded, but I think the over-specificity will hurt more than help at 
this stage.


# Current Plan

- Add "accel: NVVM" label
- Don't add "accel: qtest".
- Add "host: {Windows, BSD, Linux, macOS}" and "guest: {Windows, BSD, 
Linux, macOS}" labels.
- Migrate "os: XXX" labels to the above split. Help wanted.
- Remove the "os: XXX" labels when the above is done.
- Re-audit "target: XXX" labels and remove usages that applied to the 
host instead of the guest. Help wanted. Possibly assign new host-arch 
labels.
- Create a document in /docs/devel/gitlab-process.rst based on the 
outcome of this thread to formalize our decisions and reasonings. Future 
patches to this doc can serve as the discussion point for changing that 
process. There are other topics to discuss beyond these labels as well, 
but these three topics felt like the most pressing to address given 
where we are in our Launchpad migration process.


Less sure:

- Create host-arch: XXX labels (Unsure of name, which platforms are
  important to track? see above.)
- Create "TCG: TCI" label (Unsure of naming)


Thanks,
--js