Creation of a large number of Github issues for libc++ recently (original) (raw)
August 15, 2024, 7:16pm 1
Hi,
Some folks may have noticed a large number of issues being created on Github recently, all targeting libc++. A large portion of these issues were closed immediately after opening them. This post explains what this is all about.
We’ve been discussing using Github issues for tracking conformance in libc++ since January 2024. The goal is to move from our ad-hoc conformance tracking (which is based on CSV files and visible at e.g. libc++ C++23 Status — libc++ documentation) to Github issues and Github projects. The benefits of using Github issues are plenty, but some of the key points are:
- we can assign people to issues to make it clear who is working on what and avoid duplicate work, which has been problematic
- an issue gets updated/closed/cross-referenced automatically when we merge the PR associated to it, so there’s no risk of forgetting to update the CSV files and our status pages becoming stale
- we can more easily search for LWG issues and WG21 papers via the Github search, and in particular we can compose tags and other properties to create useful views of the work we have to do
- we can target a milestone (LLVM release) with an issue, making it easier to be intentional about what we want to focus on for an upcoming release
Those are just examples of benefits we foresee and the motivations don’t matter too much for the purpose of this post, but the bottom line is that there was consensus amongst the libc++ contributors to move to Github issues once we had figured out a few things (importantly how to sync the CSV files to github issues, which we have a solution for now).
So in the past few days, I’ve been creating Github issues for papers and DRs that we track in our CSV files. I am adding these issues to the libc++ Standards Conformance Github project. The goal is for that project to provide a comprehensive view of our conformance status.
This migration required retroactively creating a lot of Github issues for WG21 papers and DRs we had already implemented, so that the Github project would provide a full view of what’s our current status (as opposed to only what we haven’t implemented yet). That’s a lot of Github issues, of course. I am creating the issues with a script that uses the gh command-line tool but I am facing a few issues like API throttling and hard limits on the number of items in a project that make the transition slower than expected. I initially thought this would take at most a few hours but this is spreading across several days at this point.
Initially, I didn’t expect that this would have any impact beyond people subscribed to the libc++ tag, who were basically already aware of the migration and wouldn’t be bothered by the spam. However, I was made aware that folks triaging issues for the monorepo were also seeing this issue spam since they are subscribed to all new issues. I want to acknowledge that difficulty and apologize for the inconvenience. I think everyone greatly appreciates the work done by folks who triage issues and I feel bad for making their work harder by spamming their inboxes. Unfortunately, I don’t know how to avoid that.
What I suggest is for anyone experiencing such spam to filter out any issue that I create (ldionne on Github). I will update this thread once the migration is done and people can remove their filter. I expect the transition to be done some time early next week but I am dependent on a few external factors like Github so I can’t promise anything.
I hope this provides a bit of clarity to anyone who has been inconvenienced by the large spike in issue creation.
Cheers,
Louis
beanz August 15, 2024, 10:08pm 2
I don’t know if this is useful for the people working on C++ or not, but we recently had a separate GitHub repository on the LLVM organization created for tracking HLSL support in Clang:
GitHub - llvm/wg-hlsl: HLSL Working Group documentation and task tracking. (RFC).
One advantage of a separate repository is that we can file issues over on that repository without creating a lot of issues on LLVM, and they can appear in a GitHub project under LLVM (HLSL Support · GitHub). We can also move issues from the wg-hlsl repo to the LLVM repo if/when needed.
We’ve only had this a few weeks and it has been super useful to us.
ldionne August 20, 2024, 2:09pm 3
This sounds potentially useful, but I am a bit worried about adding complexity to our issue tracking. I think keeping the issues in the main repository is going to work fine in general, it’s just a real pain during this initial creation phase. Normally, we would create only a small number of issues (10-20) 3 times a year (after each meeting).
ldionne August 20, 2024, 2:09pm 4
Heads up: I had paused the issue creation as we were waiting for Github to bump the issue limit in our conformance project, which has been done now. So I am resuming with the creation of the remaining C++23 and C++26 issues.
ldionne August 21, 2024, 12:21pm 5
Alright folks, the issues have been created now. If anyone had created a filter to ignore issues created by me, you can (and should!) now remove it.
By the way, I noticed that even I don’t get emails for issues created by myself. Is it possible that a Github organization admin has created some sort of Github-level filter to reduce the spam? If so, it should now be removed.
August 22, 2024, 8:13am 6
I don’t see a link pointing to the conformance project view from the GitHub repository page:
Other repositories have a “Projects” tab. Maybe that’s what we need here.
Also it could be useful to document and link the project from the libc++ home page:
https://libcxx.llvm.org/
I don’t know if the above is missing on purpose yet but it will be useful if corrected.
ldionne August 22, 2024, 12:40pm 7
I just have not gotten around to adding that link in our documentation!