I can tell you that in LLDB we already do get CC’ed on the list for every bug. I will grant you that the volume of bugs in LLDB is much lower than other lists, but I find it very helpful. It gives visibility to bugs that would otherwise be seen by nobody.
On the other hand, I’m intentionally unsubscribed from llvm-bugs because it just generates an unbelievable volume of email. Checking the archives, there were over 700 emails in October. I’m just not going to sign up for that, and if all llvm bugs started going to llvm-dev I would probably even go one step further and unsubscribe from llvm-dev.
Slightly unrelated, but has there been any specific guidance or proposals of how to re-organize the components? They all look way too specific to me. For example, in clang we have:
C++
C++17
C++11
C++14
C++2a
CUDA
Documentation
Driver
Formatter
Frontend
Headers
libclang
LLVM Codegen
Modules
OpenCL
Static Analyzer
Tooling.
Can we cut this down to about 4? I’ll take a stab at it:
Standards Conformance
Tooling
Codegen Quality
Other
I don’t actively work on clang so feel free to ignore this, it’s just a strawman attempt at doing something.
The motivation here is that if people can quickly and easily identify the set of components they’re interested in they are more willing to subscribe themselves to those components.
I’m guessing that of the existing set of components, there is a significant amount of overlap among the set of components that individual contributors are interested in, which suggests we can compress most of them down quite a bit.