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 <dsch...@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-...@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 <ztur...@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.be...@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 <ztur...@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-...@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-ad...@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-...@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>> >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
