qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] GitLab issue tracker labeling process: arch/target, os, and ac


From: Philippe Mathieu-Daudé
Subject: Re: [RFC] GitLab issue tracker labeling process: arch/target, os, and accel labels
Date: Tue, 15 Jun 2021 22:09:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]