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. On Wed, Oct 31, 2018 at 11:25 AM Richard Smith via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Wed, 31 Oct 2018, 10:47 David Greene via cfe-dev < > cfe-...@lists.llvm.org wrote: > >> Richard Smith via cfe-dev <cfe-...@lists.llvm.org> writes: >> >> > In fact, I think it'd be entirely reasonable to subscribe cfe-dev to >> > all clang bugs (fully subscribe -- email on all updates!). I don't see >> > any reason whatsoever why a bug update should get *less* attention >> > than non-bug development discussion. >> >> Some of us are on space-limited machines (I'm thinking of personal >> equipment, not corporate infrastructure) and getting all bug updates for >> components could put a real squeeze on things. >> >> I agree that cfe-bugs, for example, should get copied on all updates but >> those updates should be opt-in. >> > > Assuming we go that way, do you think it's reasonable for someone to want > to subscribe to cfe-dev but not cfe-bugs? What's the use case for that? If > it's email volume, that choice would prioritize the discussion of "I'm not > sure this is a bug" or "what's going on here?" plus general dev discussion > and announcements (cfe-dev) over the discussion of "I'm confident that this > is a bug" (cfe-bugs). > > Perhaps we should have a separate cfe-announce list for people who want to > stay informed but not drink from the firehose of development discussion > (current cfe-dev plus clang bug updates). > > -David > > >> _______________________________________________ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > _______________________________________________ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
