[llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Kristof Beyls via llvm-dev]

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).

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.

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.
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.
I'm afraid I don't really have enough experience with github issues to know
what's possible with respect to client-side filtering.

Thanks,

Kristof

Op vr 25 okt. 2019 om 20:34 schreef Robinson, Paul <paul.robinson at sony.com>:

> > 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:
> > - You can subscribe to notification emails for activity in the entire
> llvm-project repository.
>
> 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.
>
> > - You can subscribe to notification emails on an individual issue.
> > - Someone else can CC you on an individual issue to get your attention,
> and you will get notifications from that (unless you opt-out).
> > - No emails will be sent to mailto:llvm-bugs at llvm.org for github issues.
> > - 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).
>
> 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.
> 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.
> 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.
>
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191028/41ca6af6/attachment.html>