llvm dev - Nov 2018 - [cfe-dev] [Call for Volunteers] Bug triaging

Hi Zach,

Thanks for elaborating.
I like your proposal. I agree it still groups per area of expertise. And it
makes the set of components we have easier to manage.
Before making changes though I hope to hear opinions from others on this.
What do others think?

Thanks,

Kristof

On 9 Nov 2018, at 18:05, Zachary Turner <zturner at
google.com<mailto:zturner at google.com>> wrote:

To elaborate, I didn't mean to group all components with less than 10 bugs
into one massive component.  Rather, to do it separately for each subcomponent. 
Grouping by expertise is fine, but I would argue that a component with 2 or 3
bugs filed per year is not a very useful component.  There has to be some kind
of bar for having a component otherwise you end up in the situation we have now.

If you apply this algorithm to the existing set of components, you end up with
something like this:

Clang:
* New Bugs
* C++
* Frontend
* Formatter
* LLVM Codegen
* Static Analyzer
* Driver
* Modules
* libclang
* Other

clang-tools
* clang-tidy
* Other

compiler-rt
* All Bugs

Documentation
* All Bugs

libc++
* All Bugs

libraries
* Backend:X86
* Scalar Optimizations
* Common Code Generator Code
* Backend:AMDGPU
* Loop Optimizer
* Backend:WebAssembly
* Backend:ARM
* DebugInfo
* Backend:AArch64
* MC
* GlobalISel
* Core LLVM classes
* Global Analyses
* Interprocedural Optimizations
* Support Libraries
* Backend:PowerPC
* Linker
* Transformation Utilities
* Other

lld
* ELF
* COFF
* Other

lldb
* All Bugs

LNT
* All Bugs

new-bugs
* All Bugs

OpenMP
* Clang Compiler Support
* Runtime Support

Packaging
* All Bugs

Phabricator
* All Bugs

Polly
* All Bugs

Runtime Libraries
* libprofile

Test Suite
* All Bugs

tools
* All Bugs

Website
* All Bugs

XRay
* All Bugs

I don't think it's helpful to have what essentially amounts to lots of
dead components, because it causes confusion for bug reporters as well as
triagers.  I also don't think the above split is radically different than
what is already there, and for the most part, it still *is* organized by
expertise.  It also means you need to find less volunteers to add themselves to
the cc list for various components.  Instead of needing to find a separate
volunteer for Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode Writer, and MCJIT,
each of which has only 1 bug each (so in each case you're looking for a
needle in a haystack to find the right person and get them to volunteer), you
only need to find 1 for all of them, and there's a good chance that person
will be at least somewhat familiar with backends in general and so know who the
right person to talk to is in each case.

Anyway, just my thoughts.

On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls <Kristof.Beyls at
arm.com<mailto:Kristof.Beyls at arm.com>> wrote:
Hi Zach,

Thanks for putting the data in a spreadsheet - that’s easier to navigate.

And thanks for re-raising the question whether we have the right components in
bugzilla.
As I think this could be an area for lots of different opinions, without any
near-perfect solution, it has the potential to be a discussion that drags on for
a long time.
I thought half of all bugs not getting triaged was a serious enough problem to
try and tackle first (with this mail thread) before aiming to improve the
component breakdown in bugzilla.
I think that setting default-cc lists on the components we have currently is
largely orthogonal to reducing/merging components, as we can always merge
default-cc lists when we merge components.


On actually coming up with a refined list of components: I think we’ll need to
define/agree first on what guiding principles we follow when deciding something
is worthwhile to be a separate component.
Over the past few weeks I’ve heard a number of different options, ranging over:


  *   Just make a component for every sub-directory in the source code.
  *   Just make a component for every library that gets build in the LLVM build.
  *   Make components so that each component has a significant enough number of
issues raised against it (I’m trying to paraphrase what you’re proposing below).

In my mind, the guiding principle should be:

  *   Components should reflect an area of expertise, so that each component can
have a set of recognised people that can triage and/or fix bugs against that
component.

If we’d follow that principle, I think we should not merge all components with
less than 10 bugs reported into an “Other” component.
I do agree that some merging could still probably be done. E.g. maybe all the
“clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into
a single component.

So in summary:

  *   I don’t think we need to delay assigning
volunteers-for-triaging/default-cc lists to components. If we merge components
later on, we can merge cc lists, or asks the volunteers for the relevant
components If they want to remain on the default-cc list for the merged
component.
  *   My opinion is the we should define components based on areas of expertise.

Thanks,

Kristof

On 8 Nov 2018, at 20:39, Zachary Turner <zturner at
google.com<mailto:zturner at google.com>> wrote:

Just so I'm clear, are we going to attempt to clean up and/or merge the
components?  If we are, it makes sense to do that before we start putting
ourselves as default CC's on the various components since they will just
change.  If not, it would be nice to get some clarification on that now.

I've put the above list into a spreadsheet so people can sort / filter it as
they see fit.  The link is here:

https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0

I think a good starting point would be to get rid of any component with less
than 10 bugs reported so far this year and merge them all into an
"Other" component.

On Thu, Nov 8, 2018 at 8:11 AM Kristof Beyls via cfe-dev <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Hi,

Yesterday, I’ve landed a description for how reported bugs should be flowing
through the various stages of a bug’s life (triage, fixing, closing, …) at
http://llvm.org/docs/BugLifeCycle.html.
Thanks for the many many people who provided ideas and feedback for this!

With there now being a description of what is expected during bug triaging
(http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for
more volunteers to actually do the bug triaging.
About half of all raised bugs currently don’t seem to get triaged.

The idea is to have one or more volunteers for each of the well over 100
different product/component combinations we have in bugzilla.
If you volunteer to help with triaging bugs against a specific component, we’ll
add you to the default cc list for that component, so that when a new bug is
raised against that component, you’ll get notified automatically through email.
For components with few reported bugs, a single triager may suffice. For the
high-traffic components, we’ll probably need multiple volunteers.
I’ve provided the list of product/components below that had bugs reported
against in 2018, together with how many bugs were reported against them this
year so far, as an indication for which components may need more volunteers.

I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs” components as
those tend to be components people file bugs against if they don’t have a clue
which part of clang/llvm is causing the issue they’re seeing. I believe that you
don’t need to be an expert to be able to triage most of those bugs. If you want
to learn more about llvm, volunteering to triage those bugs may be an
interesting way to learn a lot more yourself.

How can you get added to the default cc list/volunteer?
* Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get yourself
added to the default cc list of the components of your choice.
* Other way: email bugs-admin at lists.llvm.org<mailto:bugs-admin at
lists.llvm.org>
* Yet another way: just reply to this mail.

Thanks,

Kristof


new-bugs/new bugs: 535 bugs raised in 2018 (so far)
clang/C++: 296 bugs raised in 2018 (so far)
clang/-New Bugs: 260 bugs raised in 2018 (so far)
libraries/Backend: X86: 202 bugs raised in 2018 (so far)
libraries/Scalar Optimizations: 152 bugs raised in 2018 (so far)
clang/Frontend: 120 bugs raised in 2018 (so far)
lld/ELF: 120 bugs raised in 2018 (so far)
clang/Formatter: 108 bugs raised in 2018 (so far)
lldb/All Bugs: 102 bugs raised in 2018 (so far)
clang/LLVM Codegen: 100 bugs raised in 2018 (so far)
clang-tools-extra/clang-tidy: 87 bugs raised in 2018 (so far)
clang/Static Analyzer: 84 bugs raised in 2018 (so far)
libraries/Common Code Generator Code: 78 bugs raised in 2018 (so far)
libc++/All Bugs: 67 bugs raised in 2018 (so far)
lld/COFF: 64 bugs raised in 2018 (so far)
libraries/Backend: AMDGPU: 60 bugs raised in 2018 (so far)
libraries/Loop Optimizer: 44 bugs raised in 2018 (so far)
lld/All Bugs: 30 bugs raised in 2018 (so far)
clang/Driver: 30 bugs raised in 2018 (so far)
Runtime Libraries/libprofile library: 29 bugs raised in 2018 (so far)
libraries/Backend: WebAssembly: 27 bugs raised in 2018 (so far)
libraries/Backend: ARM: 25 bugs raised in 2018 (so far)
clang-tools-extra/Other: 25 bugs raised in 2018 (so far)
libraries/DebugInfo: 25 bugs raised in 2018 (so far)
OpenMP/Clang Compiler Support: 23 bugs raised in 2018 (so far)
compiler-rt/compiler-rt: 21 bugs raised in 2018 (so far)
libraries/Backend: AArch64: 19 bugs raised in 2018 (so far)
clang/C++11: 19 bugs raised in 2018 (so far)
libraries/MC: 18 bugs raised in 2018 (so far)
Build scripts/cmake: 17 bugs raised in 2018 (so far)
clang/Modules: 17 bugs raised in 2018 (so far)
libraries/GlobalISel: 17 bugs raised in 2018 (so far)
OpenMP/Runtime Library: 15 bugs raised in 2018 (so far)
libraries/Global Analyses: 14 bugs raised in 2018 (so far)
libraries/Core LLVM classes: 14 bugs raised in 2018 (so far)
clang/libclang: 14 bugs raised in 2018 (so far)
Documentation/General docs: 13 bugs raised in 2018 (so far)
Packaging/deb packages: 13 bugs raised in 2018 (so far)
libraries/Support Libraries: 13 bugs raised in 2018 (so far)
libraries/Interprocedural Optimizations: 13 bugs raised in 2018 (so far)
libraries/Backend: PowerPC: 11 bugs raised in 2018 (so far)
libraries/Linker: 11 bugs raised in 2018 (so far)
libraries/Transformation Utilities: 11 bugs raised in 2018 (so far)
clang/C++14: 10 bugs raised in 2018 (so far)
clang/Headers: 10 bugs raised in 2018 (so far)
Test Suite/lit: 10 bugs raised in 2018 (so far)
compiler-rt/profile: 10 bugs raised in 2018 (so far)
tools/llvm-objdump: 9 bugs raised in 2018 (so far)
tools/llvm-ar: 8 bugs raised in 2018 (so far)
Polly/Other: 7 bugs raised in 2018 (so far)
Polly/Optimizer: 7 bugs raised in 2018 (so far)
libraries/Register Allocator: 7 bugs raised in 2018 (so far)
tools/llc: 7 bugs raised in 2018 (so far)
XRay/Runtime: 7 bugs raised in 2018 (so far)
Packaging/Windows Installer: 6 bugs raised in 2018 (so far)
Test Suite/Programs Tests: 6 bugs raised in 2018 (so far)
clang/CUDA: 6 bugs raised in 2018 (so far)
tools/lto: 6 bugs raised in 2018 (so far)
compiler-rt/fuzzer: 6 bugs raised in 2018 (so far)
compiler-rt/msan: 6 bugs raised in 2018 (so far)
libraries/Backend: MIPS: 5 bugs raised in 2018 (so far)
tools/opt: 5 bugs raised in 2018 (so far)
Bugzilla Admin/Products: 5 bugs raised in 2018 (so far)
clang/OpenCL: 5 bugs raised in 2018 (so far)
libraries/Miscellaneous Instrumentation passes: 5 bugs raised in 2018 (so far)
tools/llvm-dwarfdump: 5 bugs raised in 2018 (so far)
compiler-rt/asan: 5 bugs raised in 2018 (so far)
clang/Documentation: 4 bugs raised in 2018 (so far)
libraries/OrcJIT: 4 bugs raised in 2018 (so far)
tools/TableGen: 4 bugs raised in 2018 (so far)
tools/bugpoint: 4 bugs raised in 2018 (so far)
Phabricator/All Bugs: 4 bugs raised in 2018 (so far)
XRay/Clang: 4 bugs raised in 2018 (so far)
libraries/Backend: AVR: 4 bugs raised in 2018 (so far)
Website/General Website: 3 bugs raised in 2018 (so far)
lld/MachO: 3 bugs raised in 2018 (so far)
libraries/Object: 3 bugs raised in 2018 (so far)
tools/llvm-objcopy: 3 bugs raised in 2018 (so far)
clang-tools-extra/Infrastructure: 3 bugs raised in 2018 (so far)
tools/llvmc: 3 bugs raised in 2018 (so far)
libraries/Target Description Classes: 3 bugs raised in 2018 (so far)
tools/llvm-config: 3 bugs raised in 2018 (so far)
libraries/LLVM assembly language parser: 3 bugs raised in 2018 (so far)
compiler-rt/builtins: 2 bugs raised in 2018 (so far)
libc++abi/All Bugs: 2 bugs raised in 2018 (so far)
compiler-rt/lsan: 2 bugs raised in 2018 (so far)
compiler-rt/ubsan: 2 bugs raised in 2018 (so far)
LNT/LNT: 2 bugs raised in 2018 (so far)
Polly/isl: 2 bugs raised in 2018 (so far)
libraries/Interprocedural Analyses: 2 bugs raised in 2018 (so far)
tools/analyze: 2 bugs raised in 2018 (so far)
Runtime Libraries/other: 1 bugs raised in 2018 (so far)
Packaging/binary tarballs: 1 bugs raised in 2018 (so far)
libraries/Backend: Hexagon: 1 bugs raised in 2018 (so far)
libraries/Bitcode Writer: 1 bugs raised in 2018 (so far)
Bugzilla Admin/Mail: 1 bugs raised in 2018 (so far)
libraries/MCJIT: 1 bugs raised in 2018 (so far)
Documentation/Doxygen: 1 bugs raised in 2018 (so far)
libraries/Backend: MSP430: 1 bugs raised in 2018 (so far)
tools/opt-viewer: 1 bugs raised in 2018 (so far)
libraries/Backend: RISC-V: 1 bugs raised in 2018 (so far)
XRay/Tools: 1 bugs raised in 2018 (so far)
clang-tools-extra/clang-query: 1 bugs raised in 2018 (so far)
Website/Documentation: 1 bugs raised in 2018 (so far)
compiler-rt/dfsan: 1 bugs raised in 2018 (so far)
libraries/Backend: PTX: 1 bugs raised in 2018 (so far)
libraries/Backend: Sparc: 1 bugs raised in 2018 (so far)
compiler-rt/cfi: 1 bugs raised in 2018 (so far)
compiler-rt/xray: 1 bugs raised in 2018 (so far)

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/3c81f3b6/attachment-0001.html>

I wonder if backends are a special case to the heuristic of "let's not
make
a bug component for code components that are too small".  LLVM is factored
to cleanly separate backend code, to the point where it's the one thing you
can leave out at compile time; this can disincentivize people to care about
bugs in backends that they don't use (and conversely backends seem like the
most common/best supported out-of-tree use case). There's obviously a lot
of variance in how actively-developed the backends are and how many people
care about them, but it seems like if we care enough to have the code
in-tree then maybe we care enough to have a bug component too.

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

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

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