I found that although we moved to Github Issues. The bug report message refers to Bugzilla still. This patch tries to update these URLs. I left FIXME for places where I am not sure how to do wording.
Details
- Reviewers
aaron.ballman asl alexander-shaposhnikov MaskRay • Quuxplusone jhenderson - Group Reviewers
Restricted Project Restricted Project - Commits
- rGbbce75e352be: Update Bug report URL to Github Issues
Diff Detail
Unit Tests
Event Timeline
llvm/docs/DeveloperPolicy.rst | ||
---|---|---|
64 ↗ | (On Diff #396451) | You can drop this and let others fix this paragraph. |
Thanks for doing this! I added few notes on the way.
clang/www/c_status.html | ||
---|---|---|
76 | The component got mapped to dedicated label in GitHub. So, it will be great to get rid of bugzilla-centric definition and switch to GitHub terms | |
clang/www/cxx_status.html | ||
80 | Ditto. Also, there are separate labels for C++11 / 14 / 20 / 23. It might make sense to mention them here | |
clang/www/get_involved.html | ||
69 | I think it would make sense to get rid of bz here. For new contributors everything should be GitHub-centric | |
libcxx/docs/index.rst | ||
220 | I'd remove bugzilla here | |
libunwind/docs/index.rst | ||
101 | And here | |
llvm/docs/HowToReleaseLLVM.rst | ||
280 ↗ | (On Diff #396451) | This is for @tstellar :) |
Will you please check the comments and reword everything using proper terminology and new things we're having on GitHub?
clang/www/c_status.html | ||
---|---|---|
76 | As I said – there is no "Clang C component" in github. We need to reword everything in terms of labels and mention correct label here. | |
clang/www/cxx_status.html | ||
80 | See above |
Tweaked English wording throughout. LGTM with all these modifications made.
Orthogonally, it does occur to me that one might save a lot of this churn (and also the next time the bug tracker moves, e.g. if we go from GitHub to something else) by simply HTTP-redirecting the front page of https://bugs.llvm.org/ to https://github.com/llvm/llvm-project/issues/ . Then we'd have a stable URL https://bugs.llvm.org/ for "reporting LLVM bugs, forever," and we could just use that stable URL everywhere. But OTOH, that's a devops task, whereas updating a bunch of documentation in the repo is easy. :)
clang-tools-extra/docs/clang-doc.rst | ||
---|---|---|
15 | Please leave the English wording as "the LLVM bugtracker" (or "the LLVM bug tracker" — really it should be two words). There is no such noun in English as "an Issues," which means that the reader won't have any idea what you're talking about here unless they click on the link to see where it goes. | |
clang/www/c_status.html | ||
75–77 | ||
clang/www/cxx_status.html | ||
79–82 | (I think , "C++17", "C++20", "C++23" would just be redundant/noise here, and would imply a thankless task for someone to go update this list every 3 years. Better to just cap it at one or two labels. The reader can be trusted to figure out that C++20 issues should be labeled with C++20.) | |
clang/www/get_involved.html | ||
68 | ||
clang/www/get_started.html | ||
22 | ||
libcxx/docs/index.rst | ||
220 | ||
libunwind/docs/index.rst | ||
101 | ||
lld/docs/_templates/indexsidebar.html | ||
3–4 ↗ | (On Diff #396509) |
libunwind/docs/index.rst | ||
---|---|---|
101 | ||
lld/docs/_templates/indexsidebar.html | ||
3–4 ↗ | (On Diff #396509) | While here, mention the labels: lld:COFF lld:ELF lld:MachO lld:wasm. |
llvm/docs/CommandGuide/llvm-objdump.rst | ||
400 | ||
llvm/docs/CommandGuide/llvm-size.rst | ||
194 | ||
llvm/docs/CommandGuide/llvm-strings.rst | ||
126 | ||
llvm/docs/CommandGuide/llvm-strip.rst | ||
197 |
libcxx/docs/index.rst | ||
---|---|---|
220 | Would https://github.com/llvm/llvm-project/labels/libc++ be better? Unfortunately "New issue" on that page does not apply the label automatically. |
llvm/docs/CommandGuide/llvm-objcopy.rst | ||
---|---|---|
539 | https://github.com/llvm/llvm-project/labels/tools:llvm-objcopy/strip You need to check whether other tools have dedicated labels. |
llvm/docs/CommandGuide/llvm-objcopy.rst | ||
---|---|---|
539 | Thanks for reminding me this. I have found there is a label for lldb too. But I don't find labels for other tools. |
llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn | ||
---|---|---|
10 | This url should redirect to github - who maintains llvm website? |
lld/docs/_templates/indexsidebar.html | ||
---|---|---|
3–4 ↗ | (On Diff #396509) | You can drop changes to this file. I updated it separately. |
llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn | ||
---|---|---|
10 | It redirects to the issue list correctly in my environment. Or you mean the url shouldn't refer to GitHub issues? I am a little bit confused. |
libcxx/docs/index.rst | ||
---|---|---|
220 | Adding parameter like in https://github.com/llvm/llvm-project/issues/new?labels=ABI could be the most direct way of doing this, given the label exists, so do assignee (untested)? Besides, the new |
libcxx/docs/index.rst | ||
---|---|---|
220 | Given that you are using the "search for label" URLs in the other places now, I think (for consistency) it does make sense to change this one to https://github.com/llvm/llvm-project/labels/libc++/. (With or without the trailing slash, but be consistent.) Please do not hard-code any links to https://github.com/llvm/llvm-project/issues/new-anything; IMHO that makes it far too likely that people (or robots) who click there will end up creating a new spam issue by accident. Someone who's found a bug to report should be taken to the search page (to search and see if it's already been filed). Taking them straight to "create a (probably spam) issue" is completely counterproductive. |
libcxx/docs/index.rst | ||
---|---|---|
220 | It's always important to check existing issues before filing a new one. I agree /new should be avoided. |
llvm/docs/CommandGuide/llvm-install-name-tool.rst | ||
---|---|---|
79 | I believe llvm-install-name-tool is a variation of llvm-objcopy, so should probably reference the llvm-objcopy URL. | |
llvm/docs/CommandGuide/llvm-otool.rst | ||
135 | I believe llvm-otool is a variation of llvm-objdump, so should reference the llvm-objdump URL. |
It looks like @asl isn't here and many experienced guys accepted this. So I think it might should be good to commit this one.
Please leave the English wording as "the LLVM bugtracker" (or "the LLVM bug tracker" — really it should be two words). There is no such noun in English as "an Issues," which means that the reader won't have any idea what you're talking about here unless they click on the link to see where it goes.