RFC: Create tickets for open libcxx papers/issues?

[h-vetinari]

Hey all

I'm following C++ conformance with interest, and was wondering if it would be welcome to open issues for individual papers (or even LWG issues) from the various status pages that are still open.

For example, trying to find the current status of what's blocking C++17 conformance is not an easy task; e.g., searches for "P0226" or "Mathematical Special Functions" turn up nothing, although there were and are PRs for it. I think having an issue each would help a lot with understanding the status/meta-info of a given paper/issue for people not already neck-deep in libcxx. They could then also conceivably be grouped with github-milestones (e.g. "C++17 conformance"), allow subscription for those interested, etc. etc.

If this is declared desirable, I wouldn't mind opening (some of) the issues & updating the tables with a new column to point to them.

CC @ldionne @mordante @Quuxplusone @zoecarver @cjdb
[no claims that this list is anywhere near complete, just took some prominent names from the assignees on the status pages]

[ldionne]

Thanks for the heads up -- I think issues were just enabled in the llvm-project repository. We'll have to start adapting our workflow to the new possibilities this opens up.

We've talked about tracking papers with GitHub several times in the past. Basically, this could come to replace our status papers. Before we start migrating to GitHub issues for tracking papers, though, we'll want to have a plan for how this is going to replace our existing status pages. Some things to think about:

• Can we find only issues related to a specific topic? (yes, tags allow that)
• Can we get some sort of conformance table like we have today in our status pages directly from GitHub issues? If so, I guess we should provide a link to that from our documentation instead of including the status pages there.

[h-vetinari]

I know that the issues got just migrated, I was waiting for that. 🙃

I'm also not proposing to replace the current status pages (though, as you say, that would be a long-term possibility), just to augment them with an additional column that points to a new github issue per (still-unimplemented) paper or LWG issue.

[mordante]

I prefer not to maintain the status in two places. That only leads to extra work and will inevitable lead to them getting out of sync. Like @ldionne I'd like to see a solution for our conformance table before we can do this.

I'm somewhat concerned about how easy GitHub issues for LWG-issues and papers can be found when only using tags. If we want to move in this direction I would like to see whether we can enable GitHub projects. Then we can have boards like https://github.com/microsoft/STL/projects/9 additionally MSVC STL uses meta issues for LWG-issues voted per plenary microsoft/STL#2236 so there are more options than just tags to find issues.

An advantage of using GitHub issues is that it's easier to "claim" an issue to avoid multiple people working on the same issue/paper.

Maybe we can do a pilot by using this for one of our large projects with multiple contributors: ranges or spaceship. There we already have a duplication and it can give us a feel how it works using GitHub issues instead of a status page. I would prefer to have that pilot with a GitHub project.

[ldionne]

I agree with @mordante, let's pilot this for Ranges. @var-const we can look at that.

[h-vetinari]

I prefer not to maintain the status in two places.

For now, I was really thinking more about having a place for meta-information (& references & instructions & "good first issue" labels etc.) per paper/LWG issue that don't fit into the tables on the status pages. It would IMO be fairly trivial to handle - when a line in the various status CSVs gets marked complete, the corresponding issue (on that same line, in a column that does not yet exist) would need to be closed as well.

I get that even that extra bit of ceremony might make people queasy, but since I'm proposing to open those issues, and I'm already regularly checking the status pages, I'd even be able to close the respective issues autonomously.

[mordante]

I understand your motivation and I see the value of being able to add this meta information.

Since we already duplicate some of the papers for the project status pages like https://libcxx.llvm.org/Status/Ranges.html I feel these are better test projects.
Especially since these projects have multiple contributors and a higher risk of two people picking up the same task. Synchronizing this with the CSV-files requires committing the changes. Being able to do that in GitHub without committing sounds like a great win to me.

We even removed the LWG-issues from this page to reduce the amount of duplication, instead we added labels on the status pages like https://libcxx.llvm.org/Status/Cxx2b.html.

So it's not just about "even that extra bit of ceremony might make people queasy", I really feel that testing with this project has more value for us.

Thanks for your offer to help! Are you on the LLVM Discord? If so it's easier to discuss this further in the libcxx chan and see how you can assist us with this pilot.

[h-vetinari]

Thanks for your offer to help! Are you on the LLVM Discord?

No, I'm not on discord unfortunately... There's an LLVM discourse that would be easier for me, but it seems that libcxx doesn't have anything there. I might get to discourse eventually, but I'm having a bit of tool account fatigue.

[h-vetinari]

There's an LLVM discourse that would be easier for me

Well, ain't I glad that things are moving to discourse. 🙃

Has there been a decision on the role (if any) of discord vs. discourse? (side note: amazingly confusing that both names are so similar)

[tstellar]

I asked this same question on discourse for the compiler side: https://llvm.discourse.group/t/github-milestone-project-for-c-20-implementation-in-clang/5809/6 Has there been any further discussion on this?

[mordante]

Based on the lack of movement on this request I'm closing it.
I also feel the bug tracker is not the best place for this discussion. So feel free to start a discussion on Discourse.

However when doing so also bring up who's going to maintain the new WG21 plenary approved items. I currently do this for our current system and it takes quite a bit of time, filing bugs will take more time and I'm not interested in doing that.