On Fri, 26 Oct 2018, 08:12 via llvm-dev <llvm-...@lists.llvm.org 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:kristof.be...@arm.com] > *Sent:* Friday, October 26, 2018 10:26 AM > *To:* Richard Smith > *Cc:* dean.ber...@gmail.com; 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 <rich...@metafoo.co.uk> wrote: > > > > On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev < > cfe-...@lists.llvm.org> wrote: > > On 5 Oct 2018, at 07:04, Dean Michael Berris <dean.ber...@gmail.com> > 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 > bugs-ad...@lists.llvm.org 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 > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
