Re: [gitlab] Renamed issue labels for target architecture

[John Snow]

On 6/13/21 2:52 AM, Stefan Weil wrote:
> Am 13.06.21 um 00:32 schrieb Richard Henderson:
>
> > I've renamed arch:* to target:* as there was some amount of confusion 
> > as to what "arch" really meant without context.  I've removed labels 
> > for lm32 and unicore32 which have been removed from qemu 6.1.  I've 
> > added a label for hexagon.

Thanks for removing those. I remembered we had removed some targets but 
could not remember which. I was going to get to it during freeze :) 
Saves me the trouble.

> > I have not yet added labels for host architecture, because I couldn't 
> > figure out how best to word the description, or even if all of the 
> > target:* labels need re-wording to emphasize target.
> >
> > And then there's the special case of TCI.
> >
> > Thoughts on these?
>
>
> A pragmatic solution for TCI could use the label "accel: TCI" as a 
> special case and instead of "accel: TCG".

I might recommend just a simple "TCI" label that can be used as a 
modifier to "accel: TCG". I thought it was nice to have a 1:1 
correlation from labels to user-facing CLI arguments for the accel 
subsystem. (i.e. they correlate to ACCEL_CLASS_NAME.)

TCI feels like a modifier to TCG. So, maybe either "TCI", or "TCG: TCI" 
so that it shows up in the label search interface when you type 'tcg'.

How do I know when to label an issue as "TCI"? I've been trying to do 
the initial labeling but sometimes the best I can do is to get it in the 
rough ballpark and wait for a subject matter expert to refine the labels.

(The difference to me is the difference between which labels that other 
maintainers may expect to use as an inbox and which they may expect to 
use for their own record-keeping.)

> We have an ambiguity for "os:" because it is unclear whether it relates 
> to the host or to the target system. That could be handled by using four 
> labels "host:", "target:" (architecture), "host-os:", "target-os:" 
> (operating system). I'd prefer dropping the "os:" label and extending 
> "target:" (and the new "host:") to allow either architecture, operating 
> system or a combination of both (for example target: i386, target: 
> i386-Windows, host: Windows).

We can probably do that -- it's easy for me to separate host/guest OS. 
But, we should probably start trying to define a formal process in 
docs/devel somewhere.

So far, it's just an informal process that Thomas and I somewhat loosely 
collaborate on. I've sent a few emails to ask about specific points, but 
we don't have a canonical document that describes them.

I have held off on proposing a document so far because we are still in 
the process of moving bugs over from launchpad -- my thought was that 
after Thomas and I had finished doing so, we could open up that discussion.

Maybe it's time to jump ahead and do it now, though.

Some points of feedback I have seen so far:

- We may want more specific labels in many places
- We may want to define labels for submaintainers directly in the 
MAINTAINERS file to establish a 1:1 mapping from Maintainer to Label
- arch: XXX tags (now target: XXX) mix concerns between host arch and 
guest arch.
- os: XXX tags mix concerns between host and guest.

I'm fine with creating as many labels as we want, but want to make sure 
it remains possible to easily triage bugs into at least preliminary 
queues without overcomplicating the label system.

I'm going to start a new thread to discuss accel, arch, and os labels. 
Let's sort it out.

> Stefan

Thanks,
--js