* [gitlab] Renamed issue labels for target architecture
@ 2021-06-12 22:32 Richard Henderson
2021-06-13 6:52 ` Stefan Weil
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Richard Henderson @ 2021-06-12 22:32 UTC (permalink / raw
To: qemu-devel, John Snow, Thomas Huth, Philippe Mathieu-Daudé
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.
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?
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gitlab] Renamed issue labels for target architecture
2021-06-12 22:32 [gitlab] Renamed issue labels for target architecture Richard Henderson
@ 2021-06-13 6:52 ` Stefan Weil
2021-06-14 16:10 ` John Snow
2021-06-14 15:11 ` John Snow
2021-06-14 16:29 ` Philippe Mathieu-Daudé
2 siblings, 1 reply; 7+ messages in thread
From: Stefan Weil @ 2021-06-13 6:52 UTC (permalink / raw
To: Richard Henderson, qemu-devel, John Snow, Thomas Huth,
Philippe Mathieu-Daudé
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.
>
> 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".
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).
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gitlab] Renamed issue labels for target architecture
2021-06-12 22:32 [gitlab] Renamed issue labels for target architecture Richard Henderson
2021-06-13 6:52 ` Stefan Weil
@ 2021-06-14 15:11 ` John Snow
2021-06-14 16:29 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 7+ messages in thread
From: John Snow @ 2021-06-14 15:11 UTC (permalink / raw
To: Richard Henderson, qemu-devel, Thomas Huth,
Philippe Mathieu-Daudé
On 6/12/21 6:32 PM, Richard Henderson wrote:
> 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.
>
> 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?
>
>
> r~
>
Well, it would have been nice to have been asked first, seeing as I have
done most of the labeling work to sift through issues.
The way the label had been being used was for both the host *and* guest,
because we had thought that fully replicating all architectures for both
host/guest tags wouldn't scale well.
I realize it is helpful to be able to search for the difference between
them, so it's fine -- but it means I have to re-audit all the labels
we've done so far so that they aren't now ... wrong.
--js
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gitlab] Renamed issue labels for target architecture
2021-06-13 6:52 ` Stefan Weil
@ 2021-06-14 16:10 ` John Snow
0 siblings, 0 replies; 7+ messages in thread
From: John Snow @ 2021-06-14 16:10 UTC (permalink / raw
To: Stefan Weil, Richard Henderson, qemu-devel, Thomas Huth,
Philippe Mathieu-Daudé, Daniel P. Berrangé,
Peter Maydell
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gitlab] Renamed issue labels for target architecture
2021-06-12 22:32 [gitlab] Renamed issue labels for target architecture Richard Henderson
2021-06-13 6:52 ` Stefan Weil
2021-06-14 15:11 ` John Snow
@ 2021-06-14 16:29 ` Philippe Mathieu-Daudé
2021-06-14 17:03 ` Richard Henderson
2021-06-14 17:18 ` Peter Maydell
2 siblings, 2 replies; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-06-14 16:29 UTC (permalink / raw
To: Richard Henderson, qemu-devel, John Snow, Thomas Huth
On 6/13/21 12:32 AM, Richard Henderson wrote:
> I've renamed arch:* to target:* as there was some amount of confusion as
> to what "arch" really meant without context.
There was a discussion with jsnow about that on IRC, and IIRC he
said what first matters to have easy tags so the reporter does the
first triage directly.
> I've removed labels for
> lm32 and unicore32 which have been removed from qemu 6.1. I've added a
> label for hexagon.
>
> 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.
We want to have a first label to quicker triage. Once a
maintainer is notified, different/finest triage can be done.
The downside is this is noisier for maintainers :(
Wait, are you seeing labels are a notification mechanism or a way
to sort the issues?
Until your rename I was using arch:s390x to contact S390 maintainers
for build failure on s390x host [Build System, arch: s390x], bug in TCG
backend or bug in TCG frontend for target [accel: TCG, arch: s390x],
hoping at least one person notified would have further look.
>
> And then there's the special case of TCI.
For reporters TCI != TCG, so the simplest is "accel: TCI",
but I prefer "accel:TCG:TCI".
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gitlab] Renamed issue labels for target architecture
2021-06-14 16:29 ` Philippe Mathieu-Daudé
@ 2021-06-14 17:03 ` Richard Henderson
2021-06-14 17:18 ` Peter Maydell
1 sibling, 0 replies; 7+ messages in thread
From: Richard Henderson @ 2021-06-14 17:03 UTC (permalink / raw
To: Philippe Mathieu-Daudé, qemu-devel, John Snow, Thomas Huth
On 6/14/21 9:29 AM, Philippe Mathieu-Daudé wrote:
> Wait, are you seeing labels are a notification mechanism or a way
> to sort the issues?
Sort the issues, primarily.
> Until your rename I was using arch:s390x to contact S390 maintainers
> for build failure on s390x host [Build System, arch: s390x], bug in TCG
> backend or bug in TCG frontend for target [accel: TCG, arch: s390x],
> hoping at least one person notified would have further look.
Ah, hmm.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gitlab] Renamed issue labels for target architecture
2021-06-14 16:29 ` Philippe Mathieu-Daudé
2021-06-14 17:03 ` Richard Henderson
@ 2021-06-14 17:18 ` Peter Maydell
1 sibling, 0 replies; 7+ messages in thread
From: Peter Maydell @ 2021-06-14 17:18 UTC (permalink / raw
To: Philippe Mathieu-Daudé
Cc: John Snow, Thomas Huth, Richard Henderson, qemu-devel
On Mon, 14 Jun 2021 at 17:32, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> Wait, are you seeing labels are a notification mechanism or a way
> to sort the issues?
I would like to use them as a sorting mechanism, which is what
I was using tags for in the old LP system. That is, sometimes
(particularly as releases approach) I want to go through and
fish out all the 'arm' issues and see if any of them are worth
tackling.
thanks
-- PMM
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-06-14 17:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-06-12 22:32 [gitlab] Renamed issue labels for target architecture Richard Henderson
2021-06-13 6:52 ` Stefan Weil
2021-06-14 16:10 ` John Snow
2021-06-14 15:11 ` John Snow
2021-06-14 16:29 ` Philippe Mathieu-Daudé
2021-06-14 17:03 ` Richard Henderson
2021-06-14 17:18 ` Peter Maydell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).