[llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Zachary Turner via llvm-dev]

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-dev at lists.llvm.org> wrote:

> On Wed, 31 Oct 2018, 10:47 David Greene via cfe-dev <
> cfe-dev at lists.llvm.org wrote:
>
>> Richard Smith via cfe-dev <cfe-dev at 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-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181031/06e83d28/attachment.html>