Zachary Turner via llvm-dev <llvm-...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
