<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Zach,
<div class=""><br class="">
</div>
<div class="">Thanks for elaborating.</div>
<div class="">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.</div>
<div class="">Before making changes though I hope to hear opinions from others on this.</div>
<div class="">What do others think?</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Kristof<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 9 Nov 2018, at 18:05, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div dir="ltr" class="">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.
<div class=""><br class="">
</div>
<div class="">If you apply this algorithm to the existing set of components, you end up with something like this:</div>
<div class=""><br class="">
</div>
<div class="">Clang:</div>
<div class="">* New Bugs</div>
<div class="">* C++</div>
<div class="">* Frontend<br class="">
</div>
<div class="">* Formatter</div>
<div class="">* LLVM Codegen</div>
<div class="">* Static Analyzer</div>
<div class="">* Driver</div>
<div class="">* Modules<br class="">
</div>
<div class="">* libclang</div>
<div class="">* Other</div>
<div class=""><br class="">
</div>
<div class="">clang-tools </div>
<div class="">* clang-tidy</div>
<div class="">* Other</div>
<div class=""> <br class="">
</div>
<div class="">compiler-rt</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">Documentation</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">libc++</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">libraries</div>
<div class="">* Backend:X86</div>
<div class="">* Scalar Optimizations</div>
<div class="">* Common Code Generator Code</div>
<div class="">* Backend:AMDGPU</div>
<div class="">* Loop Optimizer</div>
<div class="">* Backend:WebAssembly</div>
<div class="">* Backend:ARM</div>
<div class="">* DebugInfo</div>
<div class="">* Backend:AArch64</div>
<div class="">* MC</div>
<div class="">* GlobalISel</div>
<div class="">* Core LLVM classes</div>
<div class="">* Global Analyses</div>
<div class="">* Interprocedural Optimizations</div>
<div class="">* Support Libraries</div>
<div class="">* Backend:PowerPC</div>
<div class="">* Linker</div>
<div class="">* Transformation Utilities</div>
<div class="">* Other</div>
<div class=""><br class="">
</div>
<div class="">lld</div>
<div class="">* ELF</div>
<div class="">* COFF</div>
<div class="">* Other</div>
<div class=""><br class="">
</div>
<div class="">lldb</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">LNT</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">new-bugs</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">OpenMP</div>
<div class="">* Clang Compiler Support</div>
<div class="">* Runtime Support</div>
<div class=""><br class="">
</div>
<div class="">Packaging</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">Phabricator</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">Polly</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">Runtime Libraries</div>
<div class="">* libprofile</div>
<div class=""><br class="">
</div>
<div class="">Test Suite</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">tools</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">Website</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">XRay</div>
</div>
<div class="">* All Bugs</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Anyway, just my thoughts.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com" class="">Kristof.Beyls@arm.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;line-break:after-white-space" class="">Hi Zach,
<div class=""><br class="">
</div>
<div class="">Thanks for putting the data in a spreadsheet - that’s easier to navigate.</div>
<div class=""><br class="">
</div>
<div class="">And thanks for re-raising the question whether we have the right components in bugzilla.</div>
<div class="">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.</div>
<div class="">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.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""></div>
<div class="">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.</div>
<div class="">Over the past few weeks I’ve heard a number of different options, ranging over:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="m_8551051793873471295MailOutline">
<li class="">Just make a component for every sub-directory in the source code.</li><li class="">Just make a component for every library that gets build in the LLVM build.</li><li class="">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).</li></ul>
<div class=""><br class="">
</div>
</div>
<div class="">In my mind, the guiding principle should be:</div>
<div class="">
<ul class="m_8551051793873471295MailOutline">
<li class="">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.</li></ul>
<div class=""><br class="">
</div>
</div>
<div class="">If we’d follow that principle, I think we should not merge all components with less than 10 bugs reported into an “Other” component.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">So in summary:</div>
<div class="">
<ul class="m_8551051793873471295MailOutline">
<li class="">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.</li><li class="">My opinion is the we should define components based on areas of expertise.</li></ul>
<div class=""><br class="">
</div>
</div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Kristof</div>
</div>
<div style="word-wrap:break-word;line-break:after-white-space" class="">
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 8 Nov 2018, at 20:39, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div>
<br class="m_8551051793873471295Apple-interchange-newline">
<div class="">
<div class="">
<div dir="ltr" class="">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.
<div class=""><br class="">
</div>
<div class="">I've put the above list into a spreadsheet so people can sort / filter it as they see fit. The link is here:</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0" target="_blank" class="">https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0</a><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Thu, Nov 8, 2018 at 8:11 AM Kristof Beyls via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;line-break:after-white-space" class="">
<div dir="auto" style="word-wrap:break-word;line-break:after-white-space" class="">
Hi,
<div class=""><br class="">
</div>
<div class="">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 <a href="http://llvm.org/docs/BugLifeCycle.html" target="_blank" class="">http://llvm.org/docs/BugLifeCycle.html</a>.</div>
<div class="">Thanks for the many many people who provided ideas and feedback for this!</div>
<div class=""><br class="">
</div>
<div class="">With there now being a description of what is expected during bug triaging (<a href="http://llvm.org/docs/BugLifeCycle.html#triaging-bugs" target="_blank" class="">http://llvm.org/docs/BugLifeCycle.html#triaging-bugs</a>), we're looking for more
volunteers to actually do the bug triaging.</div>
<div class="">About half of all raised bugs currently don’t seem to get triaged.</div>
<div class=""><br class="">
</div>
<div class="">The idea is to have one or more volunteers for each of the well over 100 different product/component combinations we have in bugzilla.</div>
<div class="">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.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">How can you get added to the default cc list/volunteer?</div>
<div class="">* Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get yourself added to the default cc list of the components of your choice.</div>
<div class="">* Other way: email <a href="mailto:bugs-admin@lists.llvm.org" target="_blank" class="">
bugs-admin@lists.llvm.org</a></div>
<div class="">* Yet another way: just reply to this mail.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Kristof</div>
<div class=""><br class="">
</div>
<div class="">
<pre style="box-sizing:border-box;overflow:auto;padding:1px 0px;margin-top:0px;margin-bottom:0px;line-height:inherit;word-break:break-all;background-color:rgb(255,255,255);border:0px;border-top-left-radius:0px;border-top-right-radius:0px;border-bottom-right-radius:0px;border-bottom-left-radius:0px;white-space:pre-wrap;vertical-align:baseline;font-variant-ligatures:normal" class="">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)</pre>
<div class=""><br class="">
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>