<div dir="ltr">I'd like to add support for moving to github issues sooner rather than later. Not having to manually create bugzilla user accounts both gives me back some time in my day (not that important) and eliminates some of the barriers for new contributors to file or contribute to bug reports (really important).<br><br>My 2 cents to add (which I forgot at the round table) is that in general, we probably do a poor job at triaging or acknowledging new bugs that are being raised.  There are some exceptions though, for some components, where a few people very actively triage and acknowledge new bug reports. I'd hate to see this disappear. Therefore, I think it's important for people to be able to continue to easily filter updates to bugs based on components and/or keyword - so that the few that are currently motivated and perform a lot of bug triage keep on doing so - by enabling a high signal-to-noise ratio in github issue notifications for them.<div><br>I'm not sure if this is easy to do with github issues (I don't think I saw ideal solutions being described in the thread above). Maybe getting all notification emails from all bugs, and then being able to filter it client-side based on keywords will work well enough, I don't know.</div><div>I don't have a strong feel on whether we should block migration on having good enough notification filtering, but I'd like to encourage enabling good enough filtering sooner rather than later.<br></div><div>I'm afraid I don't really have enough experience with github issues to know what's possible with respect to client-side filtering.</div><div><br></div><div>Thanks,</div><div><br></div><div>Kristof</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op vr 25 okt. 2019 om 20:34 schreef Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> We do not want to build supplementary notification systems to make github issues send additional emails that it is unable to send itself. We will only support what GitHub supports. That means:<br>
> - You can subscribe to notification emails for activity in the entire llvm-project repository.<br>
<br>
Is that only new issues?  Or all activity?  If it's all activity on all issues, you're effectively auto-subscribing to all issues, and really nobody would want that.  Well, maybe, like, 3 people.<br>
<br>
> - You can subscribe to notification emails on an individual issue.<br>
> - Someone else can CC you on an individual issue to get your attention, and you will get notifications from that (unless you opt-out).<br>
> - No emails will be sent to mailto:<a href="mailto:llvm-bugs@llvm.org" target="_blank">llvm-bugs@llvm.org</a> for github issues.<br>
> - There is no builtin way for users to subscribe to emails for bugs that have a given label (for example, all "clang" issues, or all x86 issues).<br>
<br>
That last is really unfortunate.  Someone only interested in (say) LLDB issues would have to subscribe to all notifications and hope that there are enough breadcrumbs in a new issue to be able to do accurate email filtering.  It would be better to handle this in the bug tracker itself.<br>
Last year Kristof Beyls and I did a BoF on bug handling, and my memory is that a nonzero number of people were willing to be auto-CC'd on particular topics but did not want to subscribe to llvm-bugs.  This description of the github tracker means that would not be feasible, which is a step backwards.<br>
I can anticipate a counter-argument which is that someone can easily search for bugs with particular tags.  I claim that's not equivalent, because it requires action on the part of the person to go look for things, and that happens only when the person thinks of doing it.  Computers should automate the tedious parts, like alerting the people who are interested in issues with a particular tag.<br>
<br>
--paulr<br>
<br>
</blockquote></div>