This is an archive of the discontinued LLVM Phabricator instance.

Replace links to archived mailing lists by links to Discourse forums
ClosedPublic

Authored by SimplyDanny on Mar 6 2022, 2:01 PM.

Details

Reviewers
tonic
sscalpone
ldionne
aaron.ballman
Group Reviewers
Restricted Project
Restricted Project

Diff Detail

Event Timeline

SimplyDanny created this revision.Mar 6 2022, 2:01 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
SimplyDanny requested review of this revision.Mar 6 2022, 2:01 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptMar 6 2022, 2:01 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne requested changes to this revision.Mar 7 2022, 7:13 AM
ldionne added a subscriber: ldionne.

Thanks for doing this! We need to fix a few undefined references, though.

libcxx/docs/index.rst
223

I think this needs to be updated!

libunwind/docs/index.rst
103

Probably this one too.

This revision now requires changes to proceed.Mar 7 2022, 7:13 AM

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

https://discourse.llvm.org/t/memory-barrier-problem/57493
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148151.html

Also, the commits mailing lists are still hosted by mailman and remain relevant to the community for the foreseeable future.

tonic requested changes to this revision.Mar 7 2022, 11:36 AM

Thank you so much for doing this! I have added some comments inline that I would like changed.

clang/README.txt
22–23

Should this be "on" the Clang forum? Versus in.

clang/www/analyzer/menu.html.incl
37

We should retain a link to the forums here. I would change the heading to Mailing List & Forums and then add the link here too.

clang/www/demo/index.cgi
23

I would change to "on" the forums.

flang/docs/GettingInvolved.md
22–23

This is worded like it is a mailing list. I would reword to something like "Flang forums are for technical discussions, questions about writing code for, or using Flang tools."

51

I would say "on" the Flang forum.

As a side note, all the old meeting minutes should be moved to this category. I can add it to my TODO list.

llvm/docs/ExtendingLLVM.rst
17–19

"on" the forums. Sorry, just my preference :)

llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
89–90

Discourse uses a little different terminology. I would change this to "please post on the LLVM forums"

168–169

Ask "on"

SimplyDanny marked 9 inline comments as done.

Updated revision according to review comments.

clang/README.txt
22–23

You tell me. 😉 I'm not a native speaker.

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Also, the commits mailing lists are still hosted by mailman and remain relevant to the community for the foreseeable future.

I tried to keep them in all places and just replaced the "-dev" lists by references to the forum(s). Have you found a link to a commits mailing list which I removed unintentionally?

Removed duplicate target names.

tonic added a comment.Mar 7 2022, 6:23 PM

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

You do not need to worry about this. Your change is updating the locations people are to ask for help. That has changed to Discourse and this is the proper change. This is separate from the archive situation which we are actively working on and I have full confidence will be sorted out. In addition, most people are not looking for archives here, they will do a google search or search the archives (which is effectively a google search since we have limited search on our website).

Also, the commits mailing lists are still hosted by mailman and remain relevant to the community for the foreseeable future.

I tried to keep them in all places and just replaced the "-dev" lists by references to the forum(s). Have you found a link to a commits mailing list which I removed unintentionally?

Do not worry about this as you have kept all the references to commits list.

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Oh, I think these changes are *fantastic*, so I'm happy we're updating the stale references to point to the more modern place to go. Thank you for that!

There are ways to search the archives (as Tanya mentioned, you can use a google site search over them), but you have to know they exist to know to do that, which is why I'd like to retain some mention of them until the migration moves over *all* of the historical data. It's not super handy for most folks, so I don't think we need a *prominent* place for this. But it is handy for those of us who have to do a fair amount of historical digging around to see how we came to the conclusions we came to (not a common activity, but it is not uncommon for folks on standards committees to be asked "why does your implementation do X?" and need to go looking).

I think the least distracting thing we could do would be to put a superscript footnote after any link to a particular discourse forum which goes to an anchor at the bottom of the page to a footnote saying something like what I recommended below. This should keep the focus for most people on going to Discourse, it shouldn't be overly distracting or confusing to people new to the docs, but it still retains useful information that some folks need.

You do not need to worry about this.

In your opinion, that may be true; in mine, this is still a concern.

Your change is updating the locations people are to ask for help.

The change is also touching Mailing List & Forums content, which are not specifically about asking for help (they can also be for reading instead of writing).

That has changed to Discourse and this is the proper change. This is separate from the archive situation which we are actively working on and I have full confidence will be sorted out. In addition, most people are not looking for archives here, they will do a google search or search the archives (which is effectively a google search since we have limited search on our website).

The migration *lost data* and I think it's important we retain some links for those of us who do code archeology a fair amount. Old timers will certainly remember that we used to have mailing lists, but that number is going to decrease as old timers leave the community and newcomers arrive. I see value in telling people who are new to the community where they can find the full, accurate history of conversations and so I still see the need to retain *some* link for quite some time. It's trivial to retain these links with some wording like The canonical historical information from this mailing list can be found at <link>. And if we don't expect to retain that archive forever because we have full confidence we'll get all the data migrated eventually, we can add an additional sentence along the lines of This archive is expected to be removed once the migration to Discourse has been verified to not lose data. or something.

Also, the commits mailing lists are still hosted by mailman and remain relevant to the community for the foreseeable future.

I tried to keep them in all places and just replaced the "-dev" lists by references to the forum(s). Have you found a link to a commits mailing list which I removed unintentionally?

Do not worry about this as you have kept all the references to commits list.

Thanks, you're absolutely right about that -- I missed that we retained the existing links to the commits lists. Sorry for the noise there.

tonic added a comment.Mar 8 2022, 8:06 AM

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Oh, I think these changes are *fantastic*, so I'm happy we're updating the stale references to point to the more modern place to go. Thank you for that!

There are ways to search the archives (as Tanya mentioned, you can use a google site search over them), but you have to know they exist to know to do that, which is why I'd like to retain some mention of them until the migration moves over *all* of the historical data. It's not super handy for most folks, so I don't think we need a *prominent* place for this. But it is handy for those of us who have to do a fair amount of historical digging around to see how we came to the conclusions we came to (not a common activity, but it is not uncommon for folks on standards committees to be asked "why does your implementation do X?" and need to go looking).

AFAIK, we have never had link to the archives and instructed people to go search them aside from the link on the Mailman list info page. In addition, knowing they exist is also something that was not super obvious to many people who have not used Mailman. I want to avoid adding references to archives in all of these places because it defeats all the work to go and update the locations to have to go back and do it again. It is also confusing to newcomers to the project. You can easily search Discourse and while we have a few cases of migration issues, we are actively determining how widespread it is. If it is determined to be worse than we think (which right now it is minimal), then we can evaluate the next course of action.

I think the least distracting thing we could do would be to put a superscript footnote after any link to a particular discourse forum which goes to an anchor at the bottom of the page to a footnote saying something like what I recommended below. This should keep the focus for most people on going to Discourse, it shouldn't be overly distracting or confusing to people new to the docs, but it still retains useful information that some folks need.

You do not need to worry about this.

In your opinion, that may be true; in mine, this is still a concern.

I don't think its fair to ask this person to be the one to add links to the archives and handle the situation. They are being put in the middle of an argument.

Your change is updating the locations people are to ask for help.

The change is also touching Mailing List & Forums content, which are not specifically about asking for help (they can also be for reading instead of writing).

Again, we have never told people to search the archives. There isn't even a "Search" box on the archives.

That has changed to Discourse and this is the proper change. This is separate from the archive situation which we are actively working on and I have full confidence will be sorted out. In addition, most people are not looking for archives here, they will do a google search or search the archives (which is effectively a google search since we have limited search on our website).

The migration *lost data* and I think it's important we retain some links for those of us who do code archeology a fair amount. Old timers will certainly remember that we used to have mailing lists, but that number is going to decrease as old timers leave the community and newcomers arrive. I see value in telling people who are new to the community where they can find the full, accurate history of conversations and so I still see the need to retain *some* link for quite some time. It's trivial to retain these links with some wording like The canonical historical information from this mailing list can be found at <link>. And if we don't expect to retain that archive forever because we have full confidence we'll get all the data migrated eventually, we can add an additional sentence along the lines of This archive is expected to be removed once the migration to Discourse has been verified to not lose data. or something.

Again, no data has been lost and it is all in Discourse. In some situations it incorrectly determined something was a signature when it was not. We are actively identifying all the situations and working to fix them automatically. I am happy to update the migration to discourse guide with the information and status of the state of the archives and the issue with the migration we found and a link to the old archives. I do not think it's the person's responsibility who created this patch.

Also, the commits mailing lists are still hosted by mailman and remain relevant to the community for the foreseeable future.

I tried to keep them in all places and just replaced the "-dev" lists by references to the forum(s). Have you found a link to a commits mailing list which I removed unintentionally?

Do not worry about this as you have kept all the references to commits list.

Thanks, you're absolutely right about that -- I missed that we retained the existing links to the commits lists. Sorry for the noise there.

aaron.ballman requested changes to this revision.Mar 8 2022, 11:40 AM
aaron.ballman added a reviewer: aaron.ballman.

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Oh, I think these changes are *fantastic*, so I'm happy we're updating the stale references to point to the more modern place to go. Thank you for that!

There are ways to search the archives (as Tanya mentioned, you can use a google site search over them), but you have to know they exist to know to do that, which is why I'd like to retain some mention of them until the migration moves over *all* of the historical data. It's not super handy for most folks, so I don't think we need a *prominent* place for this. But it is handy for those of us who have to do a fair amount of historical digging around to see how we came to the conclusions we came to (not a common activity, but it is not uncommon for folks on standards committees to be asked "why does your implementation do X?" and need to go looking).

AFAIK, we have never had link to the archives and instructed people to go search them aside from the link on the Mailman list info page.

This patch removes the links to where the archives can be found. I have instructed people to go search those archives on multiple occasions as part of ISO standards work.

In addition, knowing they exist is also something that was not super obvious to many people who have not used Mailman. I want to avoid adding references to archives in all of these places because it defeats all the work to go and update the locations to have to go back and do it again.

I know you want to avoid all mentions of mailman. I want to avoid losing information that is still relevant for the foreseeable future. The places I want to see updated already list mailman for the commits lists, so I don't agree that my request adds a material burden for the future.

It is also confusing to newcomers to the project.

This is why I suggested using a footnote to make it much more clear that this is a secondary option. Not everyone in the project is a newcomer, but we still need to support them. I'm not at all tied to this solution of using footnotes if you have a suggestion for a less intrusive approach to accomplish the same goal.

I think the least distracting thing we could do would be to put a superscript footnote after any link to a particular discourse forum which goes to an anchor at the bottom of the page to a footnote saying something like what I recommended below. This should keep the focus for most people on going to Discourse, it shouldn't be overly distracting or confusing to people new to the docs, but it still retains useful information that some folks need.

You do not need to worry about this.

In your opinion, that may be true; in mine, this is still a concern.

I don't think its fair to ask this person to be the one to add links to the archives and handle the situation. They are being put in the middle of an argument.

The author changed a bunch of links in good ways but also did so in a way that loses information in a few places that I don't wish to see lost. You disagree. That's fine and is very normal part of patch review. It's not an argument for reviewers to find consensus among themselves when there are disagreements.

Your change is updating the locations people are to ask for help.

The change is also touching Mailing List & Forums content, which are not specifically about asking for help (they can also be for reading instead of writing).

Again, we have never told people to search the archives. There isn't even a "Search" box on the archives.

I ask folks to search the archives. I think Discourse should cover the vast majority of those situations without issue. However, not knowing that we have more complete archives elsewhere does not help those folks for whom the questions are not "it'd be nice to know" but are "I need to know." These are the people I want to continue to support.

I've added comments to the few places I'd like to see a change, which hopefully makes my request more clear. I am carefully trying to avoid adding this extra information to the places we're documenting people to go for discussion; I think those should continue to only point to Discourse. But the places where we have quick links for more useful information are where I think we should retain some unobtrusive mention of the complete archives.

clang/www/analyzer/menu.html.incl
37

I would like to see a footnote here for the old archives.

clang/www/menu.html.incl
36

I would like to see a footnote here for the old archives.

compiler-rt/www/menu.html.incl
13

I would like to see a footnote here for the old archives.

flang/docs/GettingInvolved.md
21

I'm on the fence about my request for a footnote here. On the one hand, that's consistent with all of the other places I'd like to see a change. On the other hand, flang is quite new so there's not nearly as much historical information in the archives, and my needs are far less pressing.

If a footnote appears here, then yay, but I don't insist on one either.

libcxx/docs/index.rst
222

I would like to see a footnote here for the old archives.

libunwind/docs/index.rst
99

I would like to see a footnote here for the old archives.

tonic added a comment.Mar 8 2022, 2:28 PM

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Oh, I think these changes are *fantastic*, so I'm happy we're updating the stale references to point to the more modern place to go. Thank you for that!

There are ways to search the archives (as Tanya mentioned, you can use a google site search over them), but you have to know they exist to know to do that, which is why I'd like to retain some mention of them until the migration moves over *all* of the historical data. It's not super handy for most folks, so I don't think we need a *prominent* place for this. But it is handy for those of us who have to do a fair amount of historical digging around to see how we came to the conclusions we came to (not a common activity, but it is not uncommon for folks on standards committees to be asked "why does your implementation do X?" and need to go looking).

AFAIK, we have never had link to the archives and instructed people to go search them aside from the link on the Mailman list info page.

This patch removes the links to where the archives can be found. I have instructed people to go search those archives on multiple occasions as part of ISO standards work.

In addition, knowing they exist is also something that was not super obvious to many people who have not used Mailman. I want to avoid adding references to archives in all of these places because it defeats all the work to go and update the locations to have to go back and do it again.

I know you want to avoid all mentions of mailman. I want to avoid losing information that is still relevant for the foreseeable future. The places I want to see updated already list mailman for the commits lists, so I don't agree that my request adds a material burden for the future.

It is also confusing to newcomers to the project.

This is why I suggested using a footnote to make it much more clear that this is a secondary option. Not everyone in the project is a newcomer, but we still need to support them. I'm not at all tied to this solution of using footnotes if you have a suggestion for a less intrusive approach to accomplish the same goal.

I think the least distracting thing we could do would be to put a superscript footnote after any link to a particular discourse forum which goes to an anchor at the bottom of the page to a footnote saying something like what I recommended below. This should keep the focus for most people on going to Discourse, it shouldn't be overly distracting or confusing to people new to the docs, but it still retains useful information that some folks need.

You do not need to worry about this.

In your opinion, that may be true; in mine, this is still a concern.

I don't think its fair to ask this person to be the one to add links to the archives and handle the situation. They are being put in the middle of an argument.

The author changed a bunch of links in good ways but also did so in a way that loses information in a few places that I don't wish to see lost. You disagree. That's fine and is very normal part of patch review. It's not an argument for reviewers to find consensus among themselves when there are disagreements.

Your change is updating the locations people are to ask for help.

The change is also touching Mailing List & Forums content, which are not specifically about asking for help (they can also be for reading instead of writing).

Again, we have never told people to search the archives. There isn't even a "Search" box on the archives.

I ask folks to search the archives. I think Discourse should cover the vast majority of those situations without issue. However, not knowing that we have more complete archives elsewhere does not help those folks for whom the questions are not "it'd be nice to know" but are "I need to know." These are the people I want to continue to support.

I've added comments to the few places I'd like to see a change, which hopefully makes my request more clear. I am carefully trying to avoid adding this extra information to the places we're documenting people to go for discussion; I think those should continue to only point to Discourse. But the places where we have quick links for more useful information are where I think we should retain some unobtrusive mention of the complete archives.

Without going through every single comment here (which is not to dismiss them, but I am not sure its helpful to respond to each one as I think we both want to work towards a resolution), I will propose an alternative solution that I hope has some common ground and addresses both of our concerns.

I hear you are concerned about is:

  • The archives may be missing information and therefore someone will not find the information they are looking for. You would like some reference to the archives to exist.

(You can correct me of I am wrong)

I am concerned about:

  • Where communication happens and where to find past communication to be confusing to newcomers
  • Creating more work in the future to remove more references to the mailing lists that have moved to discourse. It is a lot of work to keep documentation up to date, so the fewer spots we have outdated information, the better.
  • Creating new patterns of behavior to use Discourse as the first reference versus the mailing list archives

I would propose that we add information to Discourse that informs users of the migration issue we are working through and that *if* they encounter a topic that seems incomplete, that they can cross reference with the mailing list archives. This can be added to the banner that is displayed when users join Discourse until we decide it is no longer needed or it can be added in the FAQ/About or as an stand alone announcement on the forum itself.

I believe this solution will meet both our needs. Please let me know what you think.

aaron.ballman accepted this revision.Mar 9 2022, 4:18 AM

I've added comments to the few places I'd like to see a change, which hopefully makes my request more clear. I am carefully trying to avoid adding this extra information to the places we're documenting people to go for discussion; I think those should continue to only point to Discourse. But the places where we have quick links for more useful information are where I think we should retain some unobtrusive mention of the complete archives.

Without going through every single comment here (which is not to dismiss them, but I am not sure its helpful to respond to each one as I think we both want to work towards a resolution), I will propose an alternative solution that I hope has some common ground and addresses both of our concerns.

I hear you are concerned about is:

  • The archives may be missing information and therefore someone will not find the information they are looking for. You would like some reference to the archives to exist.

(You can correct me of I am wrong)

You have the gist of it -- I'd like some "official" place where we make it clear that these archives exist and are "ours" (as opposed to some third-party scraping service that exposes the messages while extracting ad revenue and perhaps modifying link targets for tracking, etc).

I am concerned about:

  • Where communication happens and where to find past communication to be confusing to newcomers
  • Creating more work in the future to remove more references to the mailing lists that have moved to discourse. It is a lot of work to keep documentation up to date, so the fewer spots we have outdated information, the better.
  • Creating new patterns of behavior to use Discourse as the first reference versus the mailing list archives

I think all of these are important concerns.

I would propose that we add information to Discourse that informs users of the migration issue we are working through and that *if* they encounter a topic that seems incomplete, that they can cross reference with the mailing list archives. This can be added to the banner that is displayed when users join Discourse until we decide it is no longer needed or it can be added in the FAQ/About or as an stand alone announcement on the forum itself.

I believe this solution will meet both our needs. Please let me know what you think.

Thank you for suggesting this!

This adds an extra level of indirection from putting the information in our docs, but I think that's a reasonable compromise. I'd like to avoid adding it to the FAQ if possible because I'm not certain people will think to look there if they find something that looks incomplete on Discourse. Adding it to the banner would certainly work, but might feel like we're advertising it a bit TOO much at that point. Perhaps a pinned post in just the forums that replace a mailing list? That is a bit more work when we decide the information is no longer needed, but maybe it strikes a reasonable balance?

Either way, I'm happy enough with *something* along the lines you propose here. Based on that, I don't think further changes are needed on this patch, so it LGTM. Thank you for your patience @SimplyDanny while we worked these details out, and thank you again for updating the docs!

I'm happy that you found a reasonable compromise. I like it too. ;)

Now, I ask you to help me a little bit with the workflow and the test failures. The review comments are all taken care of as far as I see. One reviewer approved the changes, others are still in a "needs changes" or an undecided state. Are approvals of all reviewers required? I guess, the test failures have nothing to do with my changes, or have they? Can we just ignore them if they are unrelated?

I'm happy that you found a reasonable compromise. I like it too. ;)

Now, I ask you to help me a little bit with the workflow and the test failures. The review comments are all taken care of as far as I see. One reviewer approved the changes, others are still in a "needs changes" or an undecided state. Are approvals of all reviewers required?

You don't need all reviewers to approve a patch before landing it, but you do need to determine if there's consensus amongst the active reviewers that it's okay to land.

I think all the review comments have been addressed here, as far as I can tell, but it's usually good to double-check just to be sure when someone has explicitly marked the review as requesting changes. I usually do that by pinging the people who marked as requesting changes (or anyone else who I'm uncertain about) and giving them a day or two to respond. If there are no responses after a few days, land the changes. If it turns out there are still comments they'd like to see addressed after the patch landed, they can generally be handled post commit (or if they're a major concern, we can always revert the changes while debating what to do). A patch is not blocked by people who are in an undecided state and haven't been active in the review at all.

@ldionne @tonic -- do things look reasonable to you now?

(btw, we have some documentation on that, in case you're not seen it: https://llvm.org/docs/CodeReview.html#code-review-workflow)

I guess, the test failures have nothing to do with my changes, or have they? Can we just ignore them if they are unrelated?

I looked at the test failures and they look unrelated, so it's fine to ignore them.

Btw, do you have commit rights for the project? If not, what name and email address would you like used for patch attribution?

I'm happy that you found a reasonable compromise. I like it too. ;)

Now, I ask you to help me a little bit with the workflow and the test failures. The review comments are all taken care of as far as I see. One reviewer approved the changes, others are still in a "needs changes" or an undecided state. Are approvals of all reviewers required? I guess, the test failures have nothing to do with my changes, or have they? Can we just ignore them if they are unrelated?

Please wait for libunwind and libc++ approval. I won't approve, because I'm not familiar with the documentation stuff.
If the test failures are unrelated you can ignore them.

I'm happy that you found a reasonable compromise. I like it too. ;)

Now, I ask you to help me a little bit with the workflow and the test failures. The review comments are all taken care of as far as I see. One reviewer approved the changes, others are still in a "needs changes" or an undecided state. Are approvals of all reviewers required? I guess, the test failures have nothing to do with my changes, or have they? Can we just ignore them if they are unrelated?

Please wait for libunwind and libc++ approval. I won't approve, because I'm not familiar with the documentation stuff.
If the test failures are unrelated you can ignore them.

Okay, I'll wait a few more days and probably ping people again if there is no response until then,

Btw, do you have commit rights for the project? If not, what name and email address would you like used for patch attribution?

I don't have commit rights. Please use "Danny Mösch" with the email address "danny.moesch@icloud.com". Thank you!

ldionne accepted this revision.Mar 16 2022, 2:04 PM

LGTM, thanks for fixing the documentation quirks in libc++/libunwind! And sorry this went under my Radar last week :-).

@tonic Is this OK with you? I don't want to override your "request for changes" by committing this.

@tonic, can you please have another look?

@tonic, can you please have another look?

If @tonic has any additional feedback, we can handle it post-commit at this point. I've gone ahead and committed this on your behalf in a749e3295df4aee18a0ad723875a6501f30ac744.

(Note, I can't close this review because of the "changes requested" state for tonic.)

tonic accepted this revision.Apr 23 2022, 10:54 AM
This revision is now accepted and ready to land.Apr 23 2022, 10:54 AM

@tonic, can you please have another look?

If @tonic has any additional feedback, we can handle it post-commit at this point. I've gone ahead and committed this on your behalf in a749e3295df4aee18a0ad723875a6501f30ac744.

(Note, I can't close this review because of the "changes requested" state for tonic.)

Thank you!

MaskRay closed this revision.Apr 23 2022, 12:31 PM
MaskRay added a subscriber: MaskRay.

a749e3295df4aee18a0ad723875a6501f30ac744 pushed by Aaron does not have a Differential Revision: line. Manual closing.