Bug tracking: bugzilla, github, ???

Clang Frontend clangd
1

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’ workflow

  • 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

2

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. You might be interested in a relevant discussion on LLVM bug lifecycle via llvm-dev.

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

I can’t think of anything better at this point and I would certainly be interested to learn what others think about it.

-Kirill

3

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. I’m not sure that timeline works :frowning:

You might be interested in a relevant discussion 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 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.

4

Hi Sam,

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

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 be there.

I’m not sure that timeline works :frowning:

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

  • discovered
  • confirmed
  • fixed

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,
-Kirill

5

[...]

Just wondering what are the current instructions for reporting bugs. I see there is now a "clangd" component in Bugzilla, which was mostly empty, so I moved all clangd-related bugs I could find under that component.

Do we use Bugzilla for now, and move to Github once the code moves there?

Simon

6

Yeah, sorry for the lack of update here. There was some discussion on llvm-dev, and also had some offline with various people.

The short version is I think:

  • we should move. Experience of *san folks reinforce this (their tracker lives at https://github.com/google/sanitizers for historical reasons)
  • “llvm monorepo” isn’t the right scope for a github bugtracker, so waiting for the source to move may not buy us much
  • the repo should be github.com/llvm/clangd, which means getting Chandler on board
  • github is a much better docs platform too, based on experiments (https://sam-mccall.github.io/clangd/)
    I haven’t managed to talk with Chandler in person yet (difficult time of year).
7

Also, thanks for doing this!