From: John Snow <jsnow@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"David Hildenbrand" <david@redhat.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Max Filippov" <jcmvbkbc@gmail.com>,
"Taylor Simpson" <tsimpson@quicinc.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
"Marek Vasut" <marex@denx.de>,
"Yoshinori Sato" <ysato@users.sourceforge.jp>,
"Kamil Rytarowski" <kamil@netbsd.org>,
"Reinoud Zandijk" <reinoud@netbsd.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Thomas Huth" <thuth@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Stefan Weil" <sw@weilnetz.de>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Greg Kurz" <groug@kaod.org>,
"Michael Rolnik" <mrolnik@gmail.com>,
"Stafford Horne" <shorne@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
"Chris Wulff" <crwulff@gmail.com>,
"Laurent Vivier" <laurent@vivier.eu>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [RFC] GitLab issue tracker labeling process: arch/target, os, and accel labels
Date: Tue, 15 Jun 2021 15:27:27 -0400 [thread overview]
Message-ID: <05a484e7-bbd3-ca9f-5642-ef98d92ad4b3@redhat.com> (raw)
In-Reply-To: <YMgLha7YL8XYrShS@yekko>
On 6/14/21 10:08 PM, David Gibson wrote:
> On Mon, Jun 14, 2021 at 01:32:11PM -0400, John Snow wrote:
>> 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.
[...]
> In general, what's the convention when a bug is independent of (say)
> the accel: does it get none of the accel tags, or all of them?
> Likewise with OS and the other categories.
So far, I have been labeling bugs reported against a specific
accel/guest/host combination with those bugs. It doesn't necessarily
mean they are bugs *in* those components. They might be, they might not be.
Generally I have been treating these labels as descriptors of the
problem environment and not necessarily descriptors of the root cause.
At a glance I often have no clue what the root cause might be. In just a
few minutes, translating some of the details of the environment into
labels in the hopes that it floats by someone with more knowledge in one
or more of those areas is the best I can do.
This *does* mean that for TCG developers, there's a high ambiguity here
because "accel: TCG" && "target: i386" applies to a pretty broad
category of reports, not all of them necessarily bugs primarily
suspected to be *about* TCG. Maybe, maybe not.
Phil sometimes removes these labels once it becomes apparent to him that
the bug doesn't actually involve the system mentioned. Maybe it was
filed under i386 but impacts all architectures, so we'd remove that label.
(Open to suggestions...)
>> # Accel
>>
>> Currently "accel: XXX", for HAX, HVF, KVM, TCG, WHPX and Xen.
>>
>> https://gitlab.com/qemu-project/qemu/-/labels?subscribed=&search=accel%3A
[...]
>> # 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}?
>
> I think that would be a good idea. Except maybe "host-os" and
> "guest-os", because "host" in particular is ambiguous with host
> architecture. (not relevant that often, but sometimes).
Easy enough.
>> # 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.
>
> Agreed. I think mixing host and guest properties together is a bad
> idea. These are relatively rarely related to each other.
> Bugs affecting multiple, but not all targets are uncommon, but not
> super rare (mostly due to chunks of code shared across several target
> archs, like ACPI and device tree).
Right. It's not super common, but I see no real reason to *enforce* that
a bug only ever has zero-or-one target label.
>> 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.
>
> Ah.. that's another general question. Are the labels supposed to
> document where the problem has been definitely observed, or a best
> estimate at where it will appear. It would be very common for a bug
> to be observed initially on only one, but quickly turn out to be
> independent of host and/or target arch.
This is a triage problem. In an ideal world, as I see it:
1. Maintainers (in general) look at the queue of "open" bugs that have
not yet been marked as triaged/confirmed/in-progress/closed/assigned/etc
2. They spend no more than a few minutes assessing the issue and
assigning some fairly broad topic labels. Ideally, at least one of these
labels will be one that a Maintainer who knows more about that area
actively receives reports for.
3. Specific subsystem maintainers watching certain labels re-label bugs
that catch their eye with far more explicit labels as they desire.
e.g. I kick a lot of things into broad labels like "Graphics", "Audio",
"Storage". At a glance, and quickly, it can be hard to get more specific
than that.
However, as an example, maybe I would glance at the Storage tag and
occasionally add a label like 'block:ATA' to pull things into a queue I
would watch more closely.
So for right now, these labels under question (accel, target, os) don't
differentiate between "observed on" and "have been definitely identified
as a problem with". They're more like hints that might wind up being wrong.
Is that the wrong idea? Maybe!
>> # Current Plan
>>
>> - Add "accel: NVVM" label
>> - Don't add "accel: qtest".
>> - Add "host: {Windows, BSD, Linux, macOS}" and "guest: {Windows, BSD, Linux,
>> macOS}" labels. >
> Again, I suggest "host-os" and "guest-os"
>
ACK
[...]
>> Less sure:
>>
>> - Create host-arch: XXX labels (Unsure of name, which platforms are
>> important to track? see above.)
>
> Maybe leave and see if looks like it would be useful?
At a glance from other feedback, that looks like the likely route. Just
kill it off and see if anyone wants it badly enough to bring it back.
--js
next prev parent reply other threads:[~2021-06-15 19:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 17:32 [RFC] GitLab issue tracker labeling process: arch/target, os, and accel labels John Snow
2021-06-14 17:42 ` Stefan Weil
2021-06-14 18:53 ` Philippe Mathieu-Daudé
2021-06-14 20:25 ` Philippe Mathieu-Daudé
2021-06-15 2:08 ` David Gibson
2021-06-15 13:56 ` Philippe Mathieu-Daudé
2021-06-16 4:38 ` David Gibson
2021-06-15 19:27 ` John Snow [this message]
2021-06-15 20:09 ` Philippe Mathieu-Daudé
2021-06-15 7:28 ` Cornelia Huck
2021-06-15 14:01 ` Philippe Mathieu-Daudé
2021-06-15 8:56 ` Thomas Huth
2021-06-15 14:03 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05a484e7-bbd3-ca9f-5642-ef98d92ad4b3@redhat.com \
--to=jsnow@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=atar4qemu@gmail.com \
--cc=berrange@redhat.com \
--cc=bin.meng@windriver.com \
--cc=crwulff@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=ehabkost@redhat.com \
--cc=groug@kaod.org \
--cc=jcmvbkbc@gmail.com \
--cc=kamil@netbsd.org \
--cc=kbastian@mail.uni-paderborn.de \
--cc=laurent@vivier.eu \
--cc=marex@denx.de \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mrolnik@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=reinoud@netbsd.org \
--cc=richard.henderson@linaro.org \
--cc=shorne@gmail.com \
--cc=sw@weilnetz.de \
--cc=thuth@redhat.com \
--cc=tsimpson@quicinc.com \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).