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

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
-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190114/da69c535/attachment.html>

I don't think that'd be a good way to implement it issue tracking with
github.

If we want to switch to github issues, we can do so within a single
repository *and* provide a tailored user experience for different
sub-products, by using issue templates. Issue templates can automatically
add issues to an appropriate label, assign to a default assignee, and
provide default text for users to fill in.

E.g., reusing "llvm-git-prototype" repository for testing, I've
created an
test issue template for clangd. Click "New Issue" here, <
https://github.com/llvm-git-prototype/llvm/issues>. Documentation for
clangd could link directly to the clangd bug template, avoiding even the
"select a template" screen.

On Mon, Jan 14, 2019 at 5:37 AM Ilya Biryukov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
> --
> Regards,
> Ilya Biryukov
> _______________________________________________
> 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/20190114/d61c1883/attachment.html>

Issue templates certainly work in single-issue-tracker approach and filing
a bug seems to be just fine with them.
See comments in my previous email about bug triaging, the fact that one
can't subscribe to be notified on certain tags only seems like a
significant flaw for a smaller-scale project like clangd.

On Mon, Jan 14, 2019 at 7:11 PM James Y Knight <jyknight at google.com>
wrote:
> I don't think that'd be a good way to implement it issue tracking
with
> github.
>
> If we want to switch to github issues, we can do so within a single
> repository *and* provide a tailored user experience for different
> sub-products, by using issue templates. Issue templates can automatically
> add issues to an appropriate label, assign to a default assignee, and
> provide default text for users to fill in.
>
> E.g., reusing "llvm-git-prototype" repository for testing,
I've created an
> test issue template for clangd. Click "New Issue" here, <
> https://github.com/llvm-git-prototype/llvm/issues>. Documentation for
> clangd could link directly to the clangd bug template, avoiding even the
> "select a template" screen.
>
> On Mon, Jan 14, 2019 at 5:37 AM Ilya Biryukov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>> --
>> 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/c3347315/attachment.html>