[clangd-dev] Bug tracking: bugzilla, github, ???
Kirill Bobyrev via clangd-dev
clangd-dev at lists.llvm.org
Mon Oct 29 05:01:30 PDT 2018
Sorry for such a huge delay. I don't know if this is still relevant as I've
seen multiple related discussion over the mailing lists but I didn't manage
to follow them and I thought I should probably finish my thoughts from way
On Fri, Oct 12, 2018 at 5:55 PM Sam McCall <sammccall at google.com> wrote:
> On Fri, Oct 12, 2018 at 3:20 PM Kirill Bobyrev <kbobyrev.lists at gmail.com>
>> Hi Sam,
>> I also think that bug tracking for Clangd is not in the best shape and it
>> would certainly be great to improve the process. However, I think that this
>> is true for most (if not all) LLVM & Clang components, so there's a room
>> for improvement.
> I agree. It seems very likely that we'll eventually end up on github
> issues. It seems very unlikely that will happen before the code moves, and
> that the code will be moved sooner than a year from now.
Are you referring to the "Moving LLVM Projects to GitHub" proposal? Oh, I
thought it's stale now. Anyway, from what I understand, the issue tracking
is not considered in that proposal, i.e. IIUC GitHub Issues are not the
proposed alternative to LLVM Bugzilla. I am not very familiar with the
proposal and the process, but I personally would think that it would be
better to use GitHub issues instead of Bugzilla if the code would already
> I'm not sure that timeline works :-(
Yes, I think it's a long time. However, if the move happens we would also
have to export the existing issues (to the new repository?) somehow, which
does not seem like *a lot* of work, but it's still some effort.
>> You might be interested in a relevant discussion
>> <https://lists.llvm.org/pipermail/llvm-dev/2018-October/126732.html> on
>> LLVM bug lifecycle via llvm-dev.
> Which part did you find relevant? It seems mostly about what happens after
> bugs get filed successfully. I'm mostly concerned about how it's too hard
> to file and find bugs.
I see. From my perspective, the common part is that there are many
obstacles for the bugs to be
While the discussion I mentioned mostly focuses on the first two parts, the
latter doesn't come without these bugs being verified by the
developers/users which makes me believe there are common problems.
> I agree that creating a GitHub page for Issues would improve the process,
>> but I am not sure whether the improvement will be significant. This would
>> also make the whole process less obvious for developers and bug reporters
>> since the process would be different from the "traditional" LLVM/Clang
>> experience while Clangd is not clearly different from the rest of the
>> tooling (e.g. it lives in the same clang-tools-extra repo).
> Agree, at least for the fraction of LLVM developers that actively use
> bugzilla - I know many mostly ignore it.
> However I think we should be prioritizing user familiarity over existing
> developer familiarity.
Fair enough, but I also think that this might be a cause of user confusion:
LLVM guidelines say "please report bugs on Bugzilla"; Clangd is a part of
LLVM source tree, but it would have a separate process. Honestly, I
personally think it would be most convinient to have Clangd as a separate
repository under github.com/llvm/clangd but I know there are multiple
opinions on that and that there are some experiments with GitHub's LLVM org
going on right now.
Again, sorry for the late reply,
>> I can't think of anything better at this point and I would certainly be
>> interested to learn what others think about it.
>> On Fri, Oct 12, 2018 at 11:18 AM Sam McCall via clangd-dev <
>> clangd-dev at lists.llvm.org> wrote:
>>> Currently I don't think we do much bug tracking at all - there are a few
>>> old issues in bugzilla.
>>> If we announce clangd as suitable for general consumption, start
>>> shipping with YCM etc for LLVM 8, we should have a reasonable channel to
>>> collect feedback and bugs.
>>> I'm not sure bugs.llvm.org is the right thing for an end-user tool:
>>> - bugzilla is an unfamiliar tool that's not part of developers'
>>> - there's no way to post a bug as a new user without emailing a
>>> human to set up an account
>>> - you have to be familiar with llvm's project structure to file a bug
>>> The most obvious alternative is github issues, as ~everyone has an
>>> account and has used the bug tracker, and it's friendly to casual new users.
>>> I *think* the easiest setup would be a separate "clangd" repo just for
>>> issue tracking and maybe docs, rather than having to fish issues out of a
>>> big llvm monorepo.
>>> Anyone have thoughts here? Particularly: anyone want to argue that
>>> bug/feature tracking is unimportant, or that the status quo is viable?
>>> Cheers, Sam
>>> clangd-dev mailing list
>>> clangd-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clangd-dev