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