Better classify what LLVM subproject is causing problems #579
Labels
Comments
kwk
added a commit
to kwk/llvm-snapshots
that referenced
this issue
Feb 24, 2025
We will no longer add `project/...` labels to our issues because we're only building the one big `llvm` project for a while now. We could invest in better classification of LLVM sub-projects as described in [this issue](fedora-llvm-team#579) but that's a different story. For now, let's remove the `project/...` label facility. NOTE: In places where the testing code was using `project/clang` for example, I've picked another label that doesn't interfere with the test. Fixes: fedora-llvm-team#1103 See: fedora-llvm-team#579
kwk
added a commit
that referenced
this issue
Feb 24, 2025
We will no longer add `project/...` labels to our issues because we're only building the one big `llvm` project for a while now. We could invest in better classification of LLVM sub-projects as described in [this issue](#579) but that's a different story. For now, let's remove the `project/...` label facility. NOTE: In places where the testing code was using `project/clang` for example, I've picked another label that doesn't interfere with the test. Fixes: #1103 See: #579
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When we still had standalone builds it was easy to point your finger at an LLVM sub-project that broke a build. We would assign a label such as
project/llvmorproject/clang. At the moment we only assignproject/llvmall the time. It would be nice if more specific labels can be added from a path of a broken compilation or test. For starters, simply taking the first bit of a path should give us the project.The text was updated successfully, but these errors were encountered: