[Call for Volunteers] Bug triaging

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
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:


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 <[hidden email]> 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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
Zachary Turner via llvm-dev <[hidden email]> writes:

> 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 agree that we could use component cleanup and that it should happen
before assigning triagers.

> 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.

Here's how I might organize things, given a clean slate:

Bugzilla

Build

clang/driver
clang/frontend
clang/llvm
clang/tools

compiler-rt

Documentation

libc++
libc++-abi

llvm/optimizer
llvm/codegen

lld

lldb

LNT

OpenMP

Packaging

Phabricator

Polly

Test Suite

Tools

Triage   # Replaces new-bugs

Website

These are not necessarily restricted to particular directory structures.
For example, an "lld" bug might very well be against a common library in
under llvm/.  I'm trying to put forward something that would make sense
to users of llvm-based compilers as well as more casual LLVM developers
while providing some categorization for broad topics (the llvm optimizer
is very different from llvm codegen, for example).


I'm not sure what should go under "Tools."  Should it be limited to
things in llvm/tools or should it include things like clang-tidy?  Maybe
we'd want an llvm/tools component and leave Tools for user-facing tools
like the clang static analyzer.  In that case clang/tools can maybe go
away.

Just some ideas.

                              -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
In reply to this post by Oleg Smolsky via cfe-dev
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 <[hidden email]> 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:


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 <[hidden email]> 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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 [hidden email]
* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] [llvm-dev] [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev

I also think that backends are a special case, and each should have its own component.  Also a code owner, which I think is already the case; and just like ensuring patches get reviewed, a backend code owner should ensure there is a triager.  It makes the list of components a bit longer, but adds no confusion to anyone trying to file a bug.

 

Actually I'd say "libraries" as a higher-level component is more confusing, as a newcomer essentially never has to deal with LLVM libraries as a concept.

--paulr

 

From: lldb-dev [mailto:[hidden email]] On Behalf Of Zachary Turner via lldb-dev
Sent: Friday, November 09, 2018 2:35 PM
To: Derek Schuff
Cc: llvm-dev; Kristof Beyls; nd; Clang Dev; LLDB Dev
Subject: Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging

 

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:

 

 

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 <[hidden email]> 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 [hidden email]

* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] [llvm-dev] [Call for Volunteers] Bug triaging

Oleg Smolsky via cfe-dev
TLDR; Please don't just straight-up remove components based on some arbitrary numeric threshold.

Just because a component doesn't get many bugs filed against it doesn't mean it isn't useful. It might just mean that the area is generally pretty stable or simply new. A good example to work with are the LLVM binary utilities, such as llvm-objdump, llvm-obcopy, llvm-strings etc. Basically all of these tools have a non-trivial amount of their code in their own source files, not shared more widely, but are individually still pretty small compared to the rest of the LLVM framework. As a result, bugs in them are unlikely to be shared with other tools (at least in terms of the cause). Let's say I only ship llvm-strings from the LLVM tools. I therefore only care about bugs in llvm-strings, and not in all the other dozen or more LLVM tools, which would end up in the "Tools: all bugs" category. I don't want to risk missing a bug in the llvm-strings tool because there are too many other bugs around. Same logic applies to each of the other tools.

Another issue with categories like "Other" is that people inevitably NEVER decide to break off a new component from it (trust me, I've seen this happen time and again with source sub-trees like "generic", "utilities", "common" etc), so you end up with Other categories with dozens of bugs that are difficult to immediately filter from one another. We have this issue already with "new-bugs": I recently went through and moved all llvm-readoj/llvm-readelf bugs into a new component to filter them from the soup of "new-bugs", but even so this was only half a dozen. Let's take the LLVM binutils as an example again. I'm going to pick on llvm-objcopy because it is a new tool that likely doesn't have that many end-users yet (it's not a reflection on the tool's quality!). As discussed, under the suggested proposal of grouping few-bug components under All bugs/Other etc, llvm-objcopy will end up under "Tools: all bugs". Let's say that a major OS starts shipping llvm-objcopy instead of GNU objcopy. This will suddenly massively increase the exposure of the tool, and potentially therefore the number of bugs reported against it. As there is no sub-component for llvm-objcopy, the bugs under Tools: all bugs will likely become dominated by llvm-objcopy, drowning out the issues with other tools. Yes, at that point we should break off the component, but I can almost guarantee that this will never happen (how do you set a threshold and whose responsibility is it to monitor that threshold? What if at some future point the number of bugs drops below that threshold?).

I said this in the BoF, and I think from an end user's point of view reporting bugs, they will in the first instance look for an executable component with the same name, so I personally believe every executable should have its own component, or for larger executables, e.g. clang and LLD, a product. Additionally, where there's a clearly defined split between large blocks of code within a large tool (e.g. LLD's COFF/ELF/Mach-O), then those should be separate components, since it's likely straightforward enough to tell which it should be in. I'm not so familiar with the library structure of the main backend and clang, since I don't regularly develop in those areas, so I'm more willing to defer to others on what further break-downs should be in that area. However, it seems clear that areas of expertise should be cleanly separated where possible (e.g. a "DWARF" component makes a lot of sense).

Maybe there should be an "Unknown" component under every Product to catch those where the user really doesn't know, but I'd prefer that to an "Other" component for reasons discussed above, as the triagers for this should first try to move it to the appropriate component (or potentially request a new one).

James

On Fri, 9 Nov 2018 at 19:48, via lldb-dev <[hidden email]> wrote:

I also think that backends are a special case, and each should have its own component.  Also a code owner, which I think is already the case; and just like ensuring patches get reviewed, a backend code owner should ensure there is a triager.  It makes the list of components a bit longer, but adds no confusion to anyone trying to file a bug.

 

Actually I'd say "libraries" as a higher-level component is more confusing, as a newcomer essentially never has to deal with LLVM libraries as a concept.

--paulr

 

From: lldb-dev [mailto:[hidden email]] On Behalf Of Zachary Turner via lldb-dev
Sent: Friday, November 09, 2018 2:35 PM
To: Derek Schuff
Cc: llvm-dev; Kristof Beyls; nd; Clang Dev; LLDB Dev
Subject: Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging

 

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:

 

 

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 <[hidden email]> 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 [hidden email]

* 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
lldb-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev