llvm dev - Jan 2019 - Proposal for an alternative bugtracking workflow

Well, it's not really critical for us _now_, because we have not switched
to github issues. And I can't really see any possibility of that happening
in the short-term, either.

Even once we do decide we want to move that way -- which we haven't yet
even done -- it'll be a long road to making it happen, and I suspect
there's many more critical missing features that we'll discover along
the
way.

IMO, the best thing to focus on for fixing issue tracking in the short
term, would be to resolve the most pressing issue in our bugzilla
installation: that users cannot file bugs, because they'll get discouraged
at step #1: creating an account.

The best thing there is to figure out how to support 'login with github'
(
https://bugs.llvm.org/show_bug.cgi?id=39430)

A next-best-thing, since that seems a lot more difficult than it should be,
would be to figure out how to re-enable account creation.

Possibly the spam overload was a temporary thing, and we can just re-enable
it.
Or, if spam remains a serious issue, quite possibly it's untargeted, and we
can fix it just by slightly tweaking the account creation form (e.g. adding
another field: "Type LLVM into the following box: [     ]", and
verifying
that that was done on the server).
Or, if it's targeted spam, maybe we have to figure out how to add a captcha
to the account create page.


On Tue, Jan 15, 2019 at 4:56 PM Chandler Carruth <chandlerc at gmail.com>
wrote:
> (briefly focused on notifications / subscriptions to tags)
>
> Somewhat regardless of whether we use a single repo of issue tracking or
> multiple repos of issue tracking, we will need this. As a concrete example,
> I suspect maintainers of a particular target will have a strong desire to
> follow issues with *that* target, but not all other targets, and yet here
> we will have enough overlap to make these necessarily go into a single
repo.
>
> As to who should own this, I think that the community as a whole *has* to
> invest in infrastructure to support excellent issue tracking. The current
> situation is actively hurting the entire project, and IMO is even more
> urgent to fix than moving the code to github. So I think there are lots of
> resources we can and should point at addressing basic missing functionality
> like notifications.
>
> Ilya, can you forward whatever ticket or tracking entry there is here?
I'd
> love to try and surface the critical nature of this for the LLVM project to
> GitHub folks.
>
> On Tue, Jan 15, 2019 at 8:03 AM Ilya Biryukov <ibiryukov at
google.com>
> wrote:
>
>> The script queries **all** issues with specified labels and
"notifies" on
>> each of those.
>> While this approach works, I doubt it would scale well if everyone is
>> doing this by hand. OTOH, building a service that does this for
everyone
>> might be feasible, albeit non-trivial and it's not clear who should
own
>> this.
>>
>> So overall having this supported by GitHub would mean a much better
UX...
>>
>>
>>
>> On Tue, Jan 15, 2019 at 3:09 PM James Y Knight <jyknight at
google.com>
>> wrote:
>>
>>> BTW, Google search found this tool:
>>> https://github.com/bcongdon/github-label-notify
>>>
>>>
>>>
>>> On Tue, Jan 15, 2019, 8:02 AM Ilya Biryukov via llvm-dev <
>>> llvm-dev at lists.llvm.org wrote:
>>>
>>>> On Tue, Jan 15, 2019 at 1:47 PM Chandler Carruth <chandlerc
at gmail.com>
>>>> wrote:
>>>>
>>>>> Has anyone reached out to GitHub about potentially enabling
this?
>>>>>
>>>> For the lack of a better place, filed a ticker against GitHub
support.
>>>> Will update the thread when they come back to me.
>>>>
>>>> --
>>>> Regards,
>>>> Ilya Biryukov
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/3b9e4e40/attachment.html>

See responses inline.

On Wed, Jan 16, 2019 at 12:31 AM James Y Knight <jyknight at google.com>
wrote:
> Well, it's not really critical for us _now_, because we have not
switched
> to github issues. And I can't really see any possibility of that
happening
> in the short-term, either.
>
Sure, the purpose of this thread was to explore what kind of issue we might
run into if that happens, not trying to build consensus/sell the move to
GitHub.

> Even once we do decide we want to move that way -- which we haven't yet
> even done -- it'll be a long road to making it happen, and I suspect
> there's many more critical missing features that we'll discover
along the
> way.
>
> IMO, the best thing to focus on for fixing issue tracking in the short
> term, would be to resolve the most pressing issue in our bugzilla
> installation: that users cannot file bugs, because they'll get
discouraged
> at step #1: creating an account.
>
The best thing there is to figure out how to support 'login with github'
(
> https://bugs.llvm.org/show_bug.cgi?id=39430)
>
A next-best-thing, since that seems a lot more difficult than it should
be,
> would be to figure out how to re-enable account creation.
>
> Possibly the spam overload was a temporary thing, and we can just
> re-enable it.
> Or, if spam remains a serious issue, quite possibly it's untargeted,
and
> we can fix it just by slightly tweaking the account creation form (e.g.
> adding another field: "Type LLVM into the following box: [    
]", and
> verifying that that was done on the server).
> Or, if it's targeted spam, maybe we have to figure out how to add a
> captcha to the account create page.
>
> On Tue, Jan 15, 2019 at 4:56 PM Chandler Carruth <chandlerc at
gmail.com>
> wrote:
>
>> (briefly focused on notifications / subscriptions to tags)
>>
>> Somewhat regardless of whether we use a single repo of issue tracking
or
>> multiple repos of issue tracking, we will need this. As a concrete
example,
>> I suspect maintainers of a particular target will have a strong desire
to
>> follow issues with *that* target, but not all other targets, and yet
here
>> we will have enough overlap to make these necessarily go into a single
repo.
>>
>> As to who should own this, I think that the community as a whole *has*
to
>> invest in infrastructure to support excellent issue tracking. The
current
>> situation is actively hurting the entire project, and IMO is even more
>> urgent to fix than moving the code to github. So I think there are lots
of
>> resources we can and should point at addressing basic missing
functionality
>> like notifications.
>>
>> Ilya, can you forward whatever ticket or tracking entry there is here?
>> I'd love to try and surface the critical nature of this for the
LLVM
>> project to GitHub folks.
>>
> I have filed a support ticket, but didn't get any public link I could
share (or any kind of response) yet.
I'll update the thread as soon as they'll come back. It might be worth
posting the same bug in one of the public repositories under
github.com/github, I just couldn't figure out which one should I use...

>> On Tue, Jan 15, 2019 at 8:03 AM Ilya Biryukov <ibiryukov at
google.com>
>> wrote:
>>
>>> The script queries **all** issues with specified labels and
"notifies"
>>> on each of those.
>>> While this approach works, I doubt it would scale well if everyone
is
>>> doing this by hand. OTOH, building a service that does this for
everyone
>>> might be feasible, albeit non-trivial and it's not clear who
should own
>>> this.
>>>
>>> So overall having this supported by GitHub would mean a much better
UX...
>>>
>>>
>>>
>>> On Tue, Jan 15, 2019 at 3:09 PM James Y Knight <jyknight at
google.com>
>>> wrote:
>>>
>>>> BTW, Google search found this tool:
>>>> https://github.com/bcongdon/github-label-notify
>>>>
>>>>
>>>>
>>>> On Tue, Jan 15, 2019, 8:02 AM Ilya Biryukov via llvm-dev <
>>>> llvm-dev at lists.llvm.org wrote:
>>>>
>>>>> On Tue, Jan 15, 2019 at 1:47 PM Chandler Carruth
<chandlerc at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Has anyone reached out to GitHub about potentially
enabling this?
>>>>>>
>>>>> For the lack of a better place, filed a ticker against
GitHub support.
>>>>> Will update the thread when they come back to me.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Ilya Biryukov
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>
>>>
>>> --
>>> Regards,
>>> Ilya Biryukov
>>>
>>
-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190117/68425f3a/attachment.html>

(cross-posting from llvm-dev in hopes to potentially get more responses,
see [2] for the original thread and sorry if you're not interested and
getting this twice)

Hi LLVM community,

As discussed earlier, we in the clangd land feel that buganizer does not
address the clangd's needs as a bug-tracking system.

In our previous attempt to raise this on llvm-dev [1] we shared our idea to
put the clangd issue tracker on GitHub. The participants raised multiple
concerns, including the migration costs, whether GitHub is the right choice
as an issue tracker, whether moving issues for clangd only will result in
unwanted community fragmentation and others

These are all valid concerns, but a big portion of the thread was focused
on migration of the existing bugs, community fragmentation issues, etc.
We feel it would also be useful to ask a more focused question on whether
using the proposed **workflow** of tracking issues in multiple GitHub
projects is a good fit for LLVM, ignoring the migration costs and such.
Please note we're not proposing to migrate from Bugzilla right away or
saying that's the only way to go forward with LLVM issue tracking, we
merely want to understand what the community thinks about the proposed
workflow and *potential* advantages and disadvantages of using it.

To reiterate, our proposal was to create a repository for each of the LLVM
subprojects under the official LLVM GitHub account, e.g.
github.com/llvm/clangd.
This repository would be run by the part of the community working on that
project and would host the issue tracker for the project. The existing '
github.com/llvm/llvm-project' repository will be used to solely host the
code, it will not have an issue tracker associated with it.

Do you think this workflow would be a good fit for tracking bugs in LLVM?

[1]: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127068.html
[2]: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129093.html


On Thu, Jan 17, 2019 at 6:52 PM Ilya Biryukov <ibiryukov at google.com>
wrote:
> See responses inline.
>
> On Wed, Jan 16, 2019 at 12:31 AM James Y Knight <jyknight at
google.com>
> wrote:
>
>> Well, it's not really critical for us _now_, because we have not
switched
>> to github issues. And I can't really see any possibility of that
happening
>> in the short-term, either.
>>
> Sure, the purpose of this thread was to explore what kind of issue we
> might run into if that happens, not trying to build consensus/sell the move
> to GitHub.
>
>
>> Even once we do decide we want to move that way -- which we haven't
yet
>> even done -- it'll be a long road to making it happen, and I
suspect
>> there's many more critical missing features that we'll discover
along the
>> way.
>>
>
>> IMO, the best thing to focus on for fixing issue tracking in the short
>> term, would be to resolve the most pressing issue in our bugzilla
>> installation: that users cannot file bugs, because they'll get
discouraged
>> at step #1: creating an account.
>>
> The best thing there is to figure out how to support 'login with
github' (
>> https://bugs.llvm.org/show_bug.cgi?id=39430)
>>
> A next-best-thing, since that seems a lot more difficult than it should
>> be, would be to figure out how to re-enable account creation.
>>
>
>> Possibly the spam overload was a temporary thing, and we can just
>> re-enable it.
>> Or, if spam remains a serious issue, quite possibly it's
untargeted, and
>> we can fix it just by slightly tweaking the account creation form (e.g.
>> adding another field: "Type LLVM into the following box: [    
]", and
>> verifying that that was done on the server).
>> Or, if it's targeted spam, maybe we have to figure out how to add a
>> captcha to the account create page.
>>
>
>> On Tue, Jan 15, 2019 at 4:56 PM Chandler Carruth <chandlerc at
gmail.com>
>> wrote:
>>
>>> (briefly focused on notifications / subscriptions to tags)
>>>
>>> Somewhat regardless of whether we use a single repo of issue
tracking or
>>> multiple repos of issue tracking, we will need this. As a concrete
example,
>>> I suspect maintainers of a particular target will have a strong
desire to
>>> follow issues with *that* target, but not all other targets, and
yet here
>>> we will have enough overlap to make these necessarily go into a
single repo.
>>>
>>> As to who should own this, I think that the community as a whole
*has*
>>> to invest in infrastructure to support excellent issue tracking.
The
>>> current situation is actively hurting the entire project, and IMO
is even
>>> more urgent to fix than moving the code to github. So I think there
are
>>> lots of resources we can and should point at addressing basic
missing
>>> functionality like notifications.
>>>
>>> Ilya, can you forward whatever ticket or tracking entry there is
here?
>>> I'd love to try and surface the critical nature of this for the
LLVM
>>> project to GitHub folks.
>>>
>> I have filed a support ticket, but didn't get any public link I
could
> share (or any kind of response) yet.
> I'll update the thread as soon as they'll come back. It might be
worth
> posting the same bug in one of the public repositories under
> github.com/github, I just couldn't figure out which one should I use...
>
>
>>> On Tue, Jan 15, 2019 at 8:03 AM Ilya Biryukov <ibiryukov at
google.com>
>>> wrote:
>>>
>>>> The script queries **all** issues with specified labels and
"notifies"
>>>> on each of those.
>>>> While this approach works, I doubt it would scale well if
everyone is
>>>> doing this by hand. OTOH, building a service that does this for
everyone
>>>> might be feasible, albeit non-trivial and it's not clear
who should own
>>>> this.
>>>>
>>>> So overall having this supported by GitHub would mean a much
better
>>>> UX...
>>>>
>>>>
>>>>
>>>> On Tue, Jan 15, 2019 at 3:09 PM James Y Knight <jyknight at
google.com>
>>>> wrote:
>>>>
>>>>> BTW, Google search found this tool:
>>>>> https://github.com/bcongdon/github-label-notify
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2019, 8:02 AM Ilya Biryukov via llvm-dev
<
>>>>> llvm-dev at lists.llvm.org wrote:
>>>>>
>>>>>> On Tue, Jan 15, 2019 at 1:47 PM Chandler Carruth
<chandlerc at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Has anyone reached out to GitHub about potentially
enabling this?
>>>>>>>
>>>>>> For the lack of a better place, filed a ticker against
GitHub
>>>>>> support. Will update the thread when they come back to
me.
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Ilya Biryukov
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Ilya Biryukov
>>>>
>>>
>
> --
> Regards,
> Ilya Biryukov
>

-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190117/d598de0d/attachment-0001.html>