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

Wed Oct 31 10:32:28 PDT 2018

On Fri, 26 Oct 2018, 08:12 via llvm-dev <llvm-dev at 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.Beyls at arm.com]
> *Sent:* Friday, October 26, 2018 10:26 AM
> *To:* Richard Smith
> *Cc:* dean.berris at 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 <richard at metafoo.co.uk> wrote:
>
>
>
> On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> On 5 Oct 2018, at 07:04, Dean Michael Berris <dean.berris at 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-admin at 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-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181031/d2e048bd/attachment.html>