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

[David Greene via lldb-dev]

Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> 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