[RFC] LLVM bug lifecycle BoF - triaging

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

Yvan Roux via cfe-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 <[hidden email]> wrote:
On Wed, 31 Oct 2018, 10:47 David Greene via cfe-dev <[hidden email] wrote:
Richard Smith via cfe-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev

Mozilla’s Bugzilla instance has a feature called “component watching”, which gives you another set of email filters (for example, receive email only on new bugs, bugs being moved to a component, and status changes). Could we try pulling that extension into the LLVM Bugzilla?

 

From: llvm-dev [mailto:[hidden email]] On Behalf Of Richard Smith via llvm-dev
Sent: Wednesday, October 31, 2018 13:32
To: Robinson, Paul <[hidden email]>
Cc: llvm-dev <[hidden email]>; [hidden email]; [hidden email]; [hidden email]
Subject: Re: [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

 

On Fri, 26 Oct 2018, 08:12 via llvm-dev <[hidden email] wrote:

As an llvm-bugs subscriber, I would prefer *not* to have email for every comment to every bug.  That's what the CC list is for.

If the admins guarantee that there is at least one auto-cc (who promises to pay attention) for each component, I think that is sufficient.

I don't agree. That is the status quo and it doesn't work. Sending email to only one person when a bug is updated is really not much better than sending email to no-one. It's unreasonable to expect a single person to triage all bugs in a component or product.

 

Auto-cc also makes it impractical to track particular bugs one is actually especially interested in. It's just not a good solution.

 

Having one bugs list per product, that receives email for all bug updates in that product, would seem like a decent solution. That way the various maintainers for that product can all subscribe and use their normal mail filters to classify the mail.

 

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.

Also +1 for UNCONFIRMED.

--paulr

 

From: Kristof Beyls [mailto:[hidden email]]
Sent: Friday, October 26, 2018 10:26 AM
To: Richard Smith
Cc: [hidden email]; llvm-dev; LLDB Dev; Clang Dev; Tanya Lattner; nd; Robinson, Paul
Subject: Re: [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

 

 

 

On 26 Oct 2018, at 04:26, Richard Smith <[hidden email]> wrote:

 

On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev <[hidden email]> wrote:

On 5 Oct 2018, at 07:04, Dean Michael Berris <[hidden email]> wrote:


Thank you for starting this conversation! I look forward to the results of the BoF discussion summarised as well.

 

Dean, all,

 

There was a lively discussion at the BoF; we’ve tried to take notes at https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture all the points. The slides used to kick start the discussion can be found at https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

 

Both at the BoF and in the mail thread, there have been many suggestions for improvements. So many that if we’d want to introduce all of them at once, we’d probably get stuck and not introduce any. To try and make progress on the ones I myself feel are most useful, I’ve volunteered for 2 actions:

 

1. Write up a proposal for documentation on what to do during bug triaging/closing/etc. I’ve just done so and put it up for review at https://reviews.llvm.org/D53691.

2. Write an email to the mailing lists to ask for volunteers for being on the “default-cc” list for components, implying you’re willing to triage bugs reported against those components. I’ve decided to first try and get consensus on what is expected when triaging a bug (see point above) before actively searching for volunteers for all components. That being said, both at the dev meeting and in the days after, I already received many requests from people to be added to the default-cc list for specific components. Of course, I’m very happy to add people volunteering to default-cc lists, so if you don’t want to wait to get added to a default-cc list, please email [hidden email] or raise it as a ticket in bugs.llvm.org under “Bugzilla Admin”/“Products”.

 

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and introduce new components in Bugzilla. We’ve implemented the changes quickly and will aim to continue to have a quick response time in the future. Please file a ticket in bugs.llvm.org under “Bugzilla Admin”/“Products” if you want to request a specific change.

 

For most of the other points that were raised: I don’t currently plan on acting on them immediately myself and hope to first see an impact of the above actions.

 

In the original post, there was a suggestion to bring back the "UNCONFIRMED" status. I think that'd be a great idea, as it both makes it easy to search for untriaged bugs and to give feedback to a reporter that their bug is real and acknowledged. Is that planned?

 

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.

However, I also think it’s a good idea, so I’ll investigate in more detail now if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I believe I’ll have to give all existing users the rights to be able to confirm bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now plan to do so, and will adapt the proposed documentation at https://reviews.llvm.org/D53691 accordingly.

Thanks for pointing to this!

 

Also, a big problem with bugzilla as we have it configured today is that commenting on an existing bug often sends mail to literally no-one. Can we reconfigure this so that llvmbugs gets mail for comments on bugs, not just for opening and closing bugs?

 

I see you’ve created https://bugs.llvm.org/show_bug.cgi?id=39445 for this in the mean time, and that a bit of discussion has started there - including whether sending an email on all comments wouldn’t result in too much spam on the llvmbugs mailing list. I don’t have a strong opinion either way myself. I hope that making sure that there is at least someone on the default-cc list for every component will result in comments on bugs being emailed to at least one person.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

Yvan Roux via cfe-dev
In reply to this post by Yvan Roux via cfe-dev

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.  

 

FTR that's roughly the same volume as llvm-dev for October already has.  So cc'ing llvm-dev on all bugs would basically double the volume.

Actually more than double, if we also start emailing every comment on every bug.

--paulr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
12