From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: John Snow <jsnow@redhat.com>, 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>,
"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 22:09:11 +0200 [thread overview]
Message-ID: <a411581b-5916-999c-dbc5-c48b055f65c8@amsat.org> (raw)
In-Reply-To: <05a484e7-bbd3-ca9f-5642-ef98d92ad4b3@redhat.com>
On 6/15/21 9:27 PM, John Snow wrote:
> 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.
I was doing this hoping it would help the triage, so further updates
won't trigger notification to the maintainers subscribed to the labels
that became irrelevant.
But now I understood other maintainers use the labels to sort bugs, so
I think we should first agree on what we expect from gitlab labels and
how to use them, before discussing on what labels to use.
Personally I see labels like a tree of IRQ lines :)
We want to always reach someone, starting broad to eventually get to
the right person able to help. The sooner we disable an IRQ where it
is not required the better, because we release uninterested maintainers
from noise, so they can attending other issues.
next prev parent reply other threads:[~2021-06-15 20:10 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
2021-06-15 20:09 ` Philippe Mathieu-Daudé [this message]
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=a411581b-5916-999c-dbc5-c48b055f65c8@amsat.org \
--to=f4bug@amsat.org \
--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=jsnow@redhat.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=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).