[lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging

[Zachary Turner via lldb-dev]

I had considered a libraries/Backends:Other as well that would be separate
from libraries/Other

On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff <dschuff at google.com> wrote:

> I wonder if backends are a special case to the heuristic of "let's not
> make a bug component for code components that are too small".  LLVM is
> factored to cleanly separate backend code, to the point where it's the one
> thing you can leave out at compile time; this can disincentivize people to
> care about bugs in backends that they don't use (and conversely backends
> seem like the most common/best supported out-of-tree use case). There's
> obviously a lot of variance in how actively-developed the backends are and
> how many people care about them, but it seems like if we care enough to
> have the code in-tree then maybe we care enough to have a bug component too.
>
> On Fri, Nov 9, 2018 at 10:45 AM Kristof Beyls via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Zach,
>>
>> Thanks for elaborating.
>> I like your proposal. I agree it still groups per area of expertise. And
>> it makes the set of components we have easier to manage.
>> Before making changes though I hope to hear opinions from others on this.
>> What do others think?
>>
>> Thanks,
>>
>> Kristof
>>
>>
>> On 9 Nov 2018, at 18:05, Zachary Turner <zturner at google.com> wrote:
>>
>> To elaborate, I didn't mean to group all components with less than 10
>> bugs into one massive component.  Rather, to do it separately for each
>> subcomponent.  Grouping by expertise is fine, but I would argue that a
>> component with 2 or 3 bugs filed per year is not a very useful component.
>> There has to be some kind of bar for having a component otherwise you end
>> up in the situation we have now.
>>
>> If you apply this algorithm to the existing set of components, you end up
>> with something like this:
>>
>> Clang:
>> * New Bugs
>> * C++
>> * Frontend
>> * Formatter
>> * LLVM Codegen
>> * Static Analyzer
>> * Driver
>> * Modules
>> * libclang
>> * Other
>>
>> clang-tools
>> * clang-tidy
>> * Other
>>
>> compiler-rt
>> * All Bugs
>>
>> Documentation
>> * All Bugs
>>
>> libc++
>> * All Bugs
>>
>> libraries
>> * Backend:X86
>> * Scalar Optimizations
>> * Common Code Generator Code
>> * Backend:AMDGPU
>> * Loop Optimizer
>> * Backend:WebAssembly
>> * Backend:ARM
>> * DebugInfo
>> * Backend:AArch64
>> * MC
>> * GlobalISel
>> * Core LLVM classes
>> * Global Analyses
>> * Interprocedural Optimizations
>> * Support Libraries
>> * Backend:PowerPC
>> * Linker
>> * Transformation Utilities
>> * Other
>>
>> lld
>> * ELF
>> * COFF
>> * Other
>>
>> lldb
>> * All Bugs
>>
>> LNT
>> * All Bugs
>>
>> new-bugs
>> * All Bugs
>>
>> OpenMP
>> * Clang Compiler Support
>> * Runtime Support
>>
>> Packaging
>> * All Bugs
>>
>> Phabricator
>> * All Bugs
>>
>> Polly
>> * All Bugs
>>
>> Runtime Libraries
>> * libprofile
>>
>> Test Suite
>> * All Bugs
>>
>> tools
>> * All Bugs
>>
>> Website
>> * All Bugs
>>
>> XRay
>> * All Bugs
>>
>> I don't think it's helpful to have what essentially amounts to lots of
>> dead components, because it causes confusion for bug reporters as well as
>> triagers.  I also don't think the above split is radically different than
>> what is already there, and for the most part, it still *is* organized by
>> expertise.  It also means you need to find less volunteers to add
>> themselves to the cc list for various components.  Instead of needing to
>> find a separate volunteer for Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode
>> Writer, and MCJIT, each of which has only 1 bug each (so in each case
>> you're looking for a needle in a haystack to find the right person and get
>> them to volunteer), you only need to find 1 for all of them, and there's a
>> good chance that person will be at least somewhat familiar with backends in
>> general and so know who the right person to talk to is in each case.
>>
>> Anyway, just my thoughts.
>>
>> On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls <Kristof.Beyls at arm.com>
>> wrote:
>>
>>> Hi Zach,
>>>
>>> Thanks for putting the data in a spreadsheet - that’s easier to navigate.
>>>
>>> And thanks for re-raising the question whether we have the right
>>> components in bugzilla.
>>> As I think this could be an area for lots of different opinions, without
>>> any near-perfect solution, it has the potential to be a discussion that
>>> drags on for a long time.
>>> I thought half of all bugs not getting triaged was a serious enough
>>> problem to try and tackle first (with this mail thread) before aiming to
>>> improve the component breakdown in bugzilla.
>>> I think that setting default-cc lists on the components we have
>>> currently is largely orthogonal to reducing/merging components, as we can
>>> always merge default-cc lists when we merge components.
>>>
>>>
>>> On actually coming up with a refined list of components: I think we’ll
>>> need to define/agree first on what guiding principles we follow when
>>> deciding something is worthwhile to be a separate component.
>>> Over the past few weeks I’ve heard a number of different options,
>>> ranging over:
>>>
>>>
>>>    - Just make a component for every sub-directory in the source code.
>>>    - Just make a component for every library that gets build in the
>>>    LLVM build.
>>>    - Make components so that each component has a significant enough
>>>    number of issues raised against it (I’m trying to paraphrase what you’re
>>>    proposing below).
>>>
>>>
>>> In my mind, the guiding principle should be:
>>>
>>>    - Components should reflect an area of expertise, so that each
>>>    component can have a set of recognised people that can triage and/or fix
>>>    bugs against that component.
>>>
>>>
>>> If we’d follow that principle, I think we should not merge all
>>> components with less than 10 bugs reported into an “Other” component.
>>> I do agree that some merging could still probably be done. E.g. maybe
>>> all the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be
>>> merged into a single component.
>>>
>>> So in summary:
>>>
>>>    - I don’t think we need to delay assigning
>>>    volunteers-for-triaging/default-cc lists to components. If we merge
>>>    components later on, we can merge cc lists, or asks the volunteers for the
>>>    relevant components If they want to remain on the default-cc list for the
>>>    merged component.
>>>    - My opinion is the we should define components based on areas of
>>>    expertise.
>>>
>>>
>>> Thanks,
>>>
>>> Kristof
>>>
>>> On 8 Nov 2018, at 20:39, Zachary Turner <zturner at google.com> wrote:
>>>
>>> Just so I'm clear, are we going to attempt to clean up and/or merge the
>>> components?  If we are, it makes sense to do that before we start putting
>>> ourselves as default CC's on the various components since they will just
>>> change.  If not, it would be nice to get some clarification on that now.
>>>
>>> I've put the above list into a spreadsheet so people can sort / filter
>>> it as they see fit.  The link is here:
>>>
>>>
>>> https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0
>>>
>>> I think a good starting point would be to get rid of any component with
>>> less than 10 bugs reported so far this year and merge them all into an
>>> "Other" component.
>>>
>>> On Thu, Nov 8, 2018 at 8:11 AM Kristof Beyls via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Yesterday, I’ve landed a description for how reported bugs should be
>>>> flowing through the various stages of a bug’s life (triage, fixing,
>>>> closing, …) at http://llvm.org/docs/BugLifeCycle.html.
>>>> Thanks for the many many people who provided ideas and feedback for
>>>> this!
>>>>
>>>> With there now being a description of what is expected during bug
>>>> triaging (http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're
>>>> looking for more volunteers to actually do the bug triaging.
>>>> About half of all raised bugs currently don’t seem to get triaged.
>>>>
>>>> The idea is to have one or more volunteers for each of the well over
>>>> 100 different product/component combinations we have in bugzilla.
>>>> If you volunteer to help with triaging bugs against a specific
>>>> component, we’ll add you to the default cc list for that component, so that
>>>> when a new bug is raised against that component, you’ll get notified
>>>> automatically through email. For components with few reported bugs, a
>>>> single triager may suffice. For the high-traffic components, we’ll probably
>>>> need multiple volunteers.
>>>> I’ve provided the list of product/components below that had bugs
>>>> reported against in 2018, together with how many bugs were reported against
>>>> them this year so far, as an indication for which components may need more
>>>> volunteers.
>>>>
>>>> I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs”
>>>> components as those tend to be components people file bugs against if they
>>>> don’t have a clue which part of clang/llvm is causing the issue they’re
>>>> seeing. I believe that you don’t need to be an expert to be able to triage
>>>> most of those bugs. If you want to learn more about llvm, volunteering to
>>>> triage those bugs may be an interesting way to learn a lot more yourself.
>>>>
>>>> How can you get added to the default cc list/volunteer?
>>>> * Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get
>>>> yourself added to the default cc list of the components of your choice.
>>>> * Other way: email bugs-admin at lists.llvm.org
>>>> * Yet another way: just reply to this mail.
>>>>
>>>> Thanks,
>>>>
>>>> Kristof
>>>>
>>>> new-bugs/new bugs: 535 bugs raised in 2018 (so far)
>>>> clang/C++: 296 bugs raised in 2018 (so far)
>>>> clang/-New Bugs: 260 bugs raised in 2018 (so far)
>>>> libraries/Backend: X86: 202 bugs raised in 2018 (so far)
>>>> libraries/Scalar Optimizations: 152 bugs raised in 2018 (so far)
>>>> clang/Frontend: 120 bugs raised in 2018 (so far)
>>>> lld/ELF: 120 bugs raised in 2018 (so far)
>>>> clang/Formatter: 108 bugs raised in 2018 (so far)
>>>> lldb/All Bugs: 102 bugs raised in 2018 (so far)
>>>> clang/LLVM Codegen: 100 bugs raised in 2018 (so far)
>>>> clang-tools-extra/clang-tidy: 87 bugs raised in 2018 (so far)
>>>> clang/Static Analyzer: 84 bugs raised in 2018 (so far)
>>>> libraries/Common Code Generator Code: 78 bugs raised in 2018 (so far)
>>>> libc++/All Bugs: 67 bugs raised in 2018 (so far)
>>>> lld/COFF: 64 bugs raised in 2018 (so far)
>>>> libraries/Backend: AMDGPU: 60 bugs raised in 2018 (so far)
>>>> libraries/Loop Optimizer: 44 bugs raised in 2018 (so far)
>>>> lld/All Bugs: 30 bugs raised in 2018 (so far)
>>>> clang/Driver: 30 bugs raised in 2018 (so far)
>>>> Runtime Libraries/libprofile library: 29 bugs raised in 2018 (so far)
>>>> libraries/Backend: WebAssembly: 27 bugs raised in 2018 (so far)
>>>> libraries/Backend: ARM: 25 bugs raised in 2018 (so far)
>>>> clang-tools-extra/Other: 25 bugs raised in 2018 (so far)
>>>> libraries/DebugInfo: 25 bugs raised in 2018 (so far)
>>>> OpenMP/Clang Compiler Support: 23 bugs raised in 2018 (so far)
>>>> compiler-rt/compiler-rt: 21 bugs raised in 2018 (so far)
>>>> libraries/Backend: AArch64: 19 bugs raised in 2018 (so far)
>>>> clang/C++11: 19 bugs raised in 2018 (so far)
>>>> libraries/MC: 18 bugs raised in 2018 (so far)
>>>> Build scripts/cmake: 17 bugs raised in 2018 (so far)
>>>> clang/Modules: 17 bugs raised in 2018 (so far)
>>>> libraries/GlobalISel: 17 bugs raised in 2018 (so far)
>>>> OpenMP/Runtime Library: 15 bugs raised in 2018 (so far)
>>>> libraries/Global Analyses: 14 bugs raised in 2018 (so far)
>>>> libraries/Core LLVM classes: 14 bugs raised in 2018 (so far)
>>>> clang/libclang: 14 bugs raised in 2018 (so far)
>>>> Documentation/General docs: 13 bugs raised in 2018 (so far)
>>>> Packaging/deb packages: 13 bugs raised in 2018 (so far)
>>>> libraries/Support Libraries: 13 bugs raised in 2018 (so far)
>>>> libraries/Interprocedural Optimizations: 13 bugs raised in 2018 (so far)
>>>> libraries/Backend: PowerPC: 11 bugs raised in 2018 (so far)
>>>> libraries/Linker: 11 bugs raised in 2018 (so far)
>>>> libraries/Transformation Utilities: 11 bugs raised in 2018 (so far)
>>>> clang/C++14: 10 bugs raised in 2018 (so far)
>>>> clang/Headers: 10 bugs raised in 2018 (so far)
>>>> Test Suite/lit: 10 bugs raised in 2018 (so far)
>>>> compiler-rt/profile: 10 bugs raised in 2018 (so far)
>>>> tools/llvm-objdump: 9 bugs raised in 2018 (so far)
>>>> tools/llvm-ar: 8 bugs raised in 2018 (so far)
>>>> Polly/Other: 7 bugs raised in 2018 (so far)
>>>> Polly/Optimizer: 7 bugs raised in 2018 (so far)
>>>> libraries/Register Allocator: 7 bugs raised in 2018 (so far)
>>>> tools/llc: 7 bugs raised in 2018 (so far)
>>>> XRay/Runtime: 7 bugs raised in 2018 (so far)
>>>> Packaging/Windows Installer: 6 bugs raised in 2018 (so far)
>>>> Test Suite/Programs Tests: 6 bugs raised in 2018 (so far)
>>>> clang/CUDA: 6 bugs raised in 2018 (so far)
>>>> tools/lto: 6 bugs raised in 2018 (so far)
>>>> compiler-rt/fuzzer: 6 bugs raised in 2018 (so far)
>>>> compiler-rt/msan: 6 bugs raised in 2018 (so far)
>>>> libraries/Backend: MIPS: 5 bugs raised in 2018 (so far)
>>>> tools/opt: 5 bugs raised in 2018 (so far)
>>>> Bugzilla Admin/Products: 5 bugs raised in 2018 (so far)
>>>> clang/OpenCL: 5 bugs raised in 2018 (so far)
>>>> libraries/Miscellaneous Instrumentation passes: 5 bugs raised in 2018 (so far)
>>>> tools/llvm-dwarfdump: 5 bugs raised in 2018 (so far)
>>>> compiler-rt/asan: 5 bugs raised in 2018 (so far)
>>>> clang/Documentation: 4 bugs raised in 2018 (so far)
>>>> libraries/OrcJIT: 4 bugs raised in 2018 (so far)
>>>> tools/TableGen: 4 bugs raised in 2018 (so far)
>>>> tools/bugpoint: 4 bugs raised in 2018 (so far)
>>>> Phabricator/All Bugs: 4 bugs raised in 2018 (so far)
>>>> XRay/Clang: 4 bugs raised in 2018 (so far)
>>>> libraries/Backend: AVR: 4 bugs raised in 2018 (so far)
>>>> Website/General Website: 3 bugs raised in 2018 (so far)
>>>> lld/MachO: 3 bugs raised in 2018 (so far)
>>>> libraries/Object: 3 bugs raised in 2018 (so far)
>>>> tools/llvm-objcopy: 3 bugs raised in 2018 (so far)
>>>> clang-tools-extra/Infrastructure: 3 bugs raised in 2018 (so far)
>>>> tools/llvmc: 3 bugs raised in 2018 (so far)
>>>> libraries/Target Description Classes: 3 bugs raised in 2018 (so far)
>>>> tools/llvm-config: 3 bugs raised in 2018 (so far)
>>>> libraries/LLVM assembly language parser: 3 bugs raised in 2018 (so far)
>>>> compiler-rt/builtins: 2 bugs raised in 2018 (so far)
>>>> libc++abi/All Bugs: 2 bugs raised in 2018 (so far)
>>>> compiler-rt/lsan: 2 bugs raised in 2018 (so far)
>>>> compiler-rt/ubsan: 2 bugs raised in 2018 (so far)
>>>> LNT/LNT: 2 bugs raised in 2018 (so far)
>>>> Polly/isl: 2 bugs raised in 2018 (so far)
>>>> libraries/Interprocedural Analyses: 2 bugs raised in 2018 (so far)
>>>> tools/analyze: 2 bugs raised in 2018 (so far)
>>>> Runtime Libraries/other: 1 bugs raised in 2018 (so far)
>>>> Packaging/binary tarballs: 1 bugs raised in 2018 (so far)
>>>> libraries/Backend: Hexagon: 1 bugs raised in 2018 (so far)
>>>> libraries/Bitcode Writer: 1 bugs raised in 2018 (so far)
>>>> Bugzilla Admin/Mail: 1 bugs raised in 2018 (so far)
>>>> libraries/MCJIT: 1 bugs raised in 2018 (so far)
>>>> Documentation/Doxygen: 1 bugs raised in 2018 (so far)
>>>> libraries/Backend: MSP430: 1 bugs raised in 2018 (so far)
>>>> tools/opt-viewer: 1 bugs raised in 2018 (so far)
>>>> libraries/Backend: RISC-V: 1 bugs raised in 2018 (so far)
>>>> XRay/Tools: 1 bugs raised in 2018 (so far)
>>>> clang-tools-extra/clang-query: 1 bugs raised in 2018 (so far)
>>>> Website/Documentation: 1 bugs raised in 2018 (so far)
>>>> compiler-rt/dfsan: 1 bugs raised in 2018 (so far)
>>>> libraries/Backend: PTX: 1 bugs raised in 2018 (so far)
>>>> libraries/Backend: Sparc: 1 bugs raised in 2018 (so far)
>>>> compiler-rt/cfi: 1 bugs raised in 2018 (so far)
>>>> compiler-rt/xray: 1 bugs raised in 2018 (so far)
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20181109/8a8268c8/attachment-0001.html>