Replace links to archived mailing lists by links to Discourse forums

[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.

[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:

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]

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]

Updated revision according to review comments.

clang/README.txt

22–23

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

[SimplyDanny]

In D121078#3363856, @aaron.ballman wrote:

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.

In D121078#3363856, @aaron.ballman wrote:

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?

[SimplyDanny]

Removed duplicate target names.

[tonic]

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

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).

In D121078#3363856, @aaron.ballman wrote:

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.

[aaron.ballman]

In D121078#3366025, @tonic wrote:

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

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.

In D121078#3363856, @aaron.ballman wrote:

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]

In D121078#3366825, @aaron.ballman wrote:

In D121078#3366025, @tonic wrote:

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

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.

In D121078#3363856, @aaron.ballman wrote:

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]

In D121078#3367289, @tonic wrote:

In D121078#3366825, @aaron.ballman wrote:

In D121078#3366025, @tonic wrote:

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

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]

In D121078#3367950, @aaron.ballman wrote:

In D121078#3367289, @tonic wrote:

In D121078#3366825, @aaron.ballman wrote:

In D121078#3366025, @tonic wrote:

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

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]

In D121078#3368424, @tonic wrote:

In D121078#3367950, @aaron.ballman wrote:

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!

[SimplyDanny]

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?

[aaron.ballman]

In D121078#3373081, @SimplyDanny wrote:

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?

[philnik]

In D121078#3373081, @SimplyDanny wrote:

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.

[SimplyDanny]

In D121078#3373139, @philnik wrote:

In D121078#3373081, @SimplyDanny wrote:

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,

In D121078#3373128, @aaron.ballman wrote:

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 "[e-mail]". Thank you!

[ldionne]

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.

[SimplyDanny]

@tonic, can you please have another look?

[aaron.ballman]

In D121078#3400810, @SimplyDanny wrote:

@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]

In D121078#3402469, @aaron.ballman wrote:

In D121078#3400810, @SimplyDanny wrote:

@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]

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

clang-tools-extra/README.txt

 //===----------------------------------------------------------------------===//
 // Clang Tools repository
 //===----------------------------------------------------------------------===//
 
 Welcome to the repository of extra Clang Tools.  This repository holds tools
 that are developed as part of the LLVM compiler infrastructure project and the
 Clang frontend.  These tools are kept in a separate "extra" repository to
 allow lighter weight checkouts of the core Clang codebase.
 
 This repository is only intended to be checked out inside of a full LLVM+Clang
 tree, and in the 'tools/extra' subdirectory of the Clang checkout.
 
 All discussion regarding Clang, Clang-based tools, and code in this repository
-should be held using the standard Clang mailing lists:
-  http://lists.llvm.org/mailman/listinfo/cfe-dev
+should be held using the standard Clang forum:
+  https://discourse.llvm.org/c/clang
 
 Code review for this tree should take place on the standard Clang patch and
 commit lists:
   http://lists.llvm.org/mailman/listinfo/cfe-commits
 
 If you find a bug in these tools, please file it in the LLVM bug tracker:
   http://llvm.org/bugs/

clang/README.txt

 the relevant web sites.  Here are some pointers:
 
 Information on Clang:             http://clang.llvm.org/
 Building and using Clang:         http://clang.llvm.org/get_started.html
 Clang Static Analyzer:            http://clang-analyzer.llvm.org/
 Information on the LLVM project:  http://llvm.org/
 
 If you have questions or comments about Clang, a great place to discuss them is
-on the Clang development mailing list:
-  http://lists.llvm.org/mailman/listinfo/cfe-dev
+on the Clang forums:
+  https://discourse.llvm.org/c/clang/
 
 If you find a bug in Clang, please file it in the LLVM bug tracker:
   http://llvm.org/bugs/

clang/www/analyzer/menu.html.incl

<li>
   Development
   <ul>
     <li><a href="/checker_dev_manual.html">Checker Developer Manual</a></li>
     <li><a href="/open_projects.html">Open Projects</a></li>
     <li><a href="/potential_checkers.html">Potential Future Checkers</a></li>
   </ul>
 </li>
 <li>
-  Mailing Lists
+  Mailing List & Forums
   <ul>
-    <li><a href="http://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev</a></li>
+    <li><a href="https://discourse.llvm.org/c/clang">Clang Frontend Forums</a></li>
     <li><a href="http://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits</a></li>
   </ul>
 </li>
 </ul>
 </td></tr>
 </table>

clang/www/demo/index.cgi

 
 open( STDERR, ">&STDOUT" ) or die "can't redirect stderr to stdout";
 
 if ( !-d $ROOT ) { mkdir( $ROOT, 0777 ); }
 
 my $LOGFILE         = "$ROOT/log.txt";
 my $FORM_URL        = 'index.cgi';
 my $MAILADDR        = '[e-mail]';
-my $CONTACT_ADDRESS = 'Questions or comments?  Email the <a href="http://lists.llvm.org/mailman/listinfo/llvm-dev">LLVM-dev mailing list</a>.';
+my $CONTACT_ADDRESS = 'Questions or comments?  Discuss on the <a href="https://discourse.llvm.org">LLVM forum</a>.';
 my $LOGO_IMAGE_URL  = 'cathead.png';
 my $TIMEOUTAMOUNT   = 20;
 $ENV{'LD_LIBRARY_PATH'} = '/home/vadve/shared/localtools/fc1/lib/';
 
 my @PREPENDPATHDIRS =
   (  
     '/home/vadve/shared/llvm-gcc4.0-2.1/bin/',
     '/home/vadve/shared/llvm-2.1/Release/bin');

clang/www/menu.html.incl

<div id="menu">
   <div class="submenu">
     <label>Clang Tools</label>
     <a href="http://clang-analyzer.llvm.org">Automatic Bug-Finding</a>
     <a href="/docs/Tooling.html">Writing Clang Tools</a>
   </div>
 
   <div class="submenu">
     <label>Communication</label>
-    <a href="http://lists.llvm.org/mailman/listinfo/cfe-users">cfe-users List</a>
-    <a href="http://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev List</a>
+    <a href="https://discourse.llvm.org/c/clang">Clang Forum</a>
     <a href="http://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits List</a>
     <a href="https://github.com/llvm/llvm-project/issues">Bug Reports</a>
     <a href="http://planet.clang.org/">Planet Clang</a>
     <a href="irc://irc.oftc.net/llvm">IRC: irc.oftc.net#llvm</a>
   </div>
 
   <div class="submenu">
     <label>The Code</label>

compiler-rt/www/menu.html.incl

 <div id="menu">
   <div>
     <a href="http://llvm.org/">LLVM Home</a>
   </div>
   
   <div class="submenu">
     <label>compiler-rt Info</label>
     <a href="/index.html">About</a>
   </div>
 
   <div class="submenu">
     <label>Quick Links</label>
-    <a href="http://lists.llvm.org/mailman/listinfo/llvm-dev">llvm-dev</a>
+    <a href="https://discourse.llvm.org">LLVM Forum</a>
     <a href="http://lists.llvm.org/mailman/listinfo/llvm-commits">llvm-commits</a>
     <a href="http://llvm.org/bugs/">Bug Reports</a>
     <a href="https://github.com/llvm/llvm-project/tree/main/compiler-rt/">Browse Sources</a>
   </div>
 </div>

flang/docs/GettingInvolved.md

 .. contents::
    :local:
 ```
 
 The Flang Project welcomes contributions of all kinds.
 Please feel free to join the mailing list or the slack channel for discussions related to development of Flang.
 To understand the status of various developments in Flang please join the respective call.
 
-## Mailing Lists
+## Forum and Mailing Lists
 
-[Developer's List (flang-dev)](http://lists.llvm.org/mailman/listinfo/flang-dev)
+[Forum](https://discourse.llvm.org/c/subprojects/flang)
 
-  This list is for people who want to be included in technical discussions related to Flang. People post to this list when they have questions about writing code
-  for or using the Flang tools. It is relatively low volume.
+  Flang forums are for technical discussions, questions about writing code for, or using Flang tools.
 
 
 [Commits Archive (flang-commits)](http://lists.llvm.org/pipermail/flang-commits)
 
   This list contains all commit messages that are made when Flang developers
   commit code changes to the repository. It also serves as a forum for
   patch review (i.e. send patches here). It is useful for those who want to
   stay on the bleeding edge of Flang development. This list is high

 
 ### Flang Community Biweekly Call
 
 -   General updates on the Flang Project, both LLVM Flang and current Flang.
 -   Join [Flang Community Biweekly Call](https://lanl-us.webex.com/lanl-us/j.php?MTID=mdce13c9bd55202e8071d8128fb953614)
 -   Time: On Wednesdays 8:30 Pacific Time, on the weeks alternating with regular Flang Community Technical Biweekly Call.
 -   Meeting minutes are available in this [Google Doc](https://docs.google.com/document/d/10T-S2J3GrahpG4Ooif93NSTz2zBW0MQc_RlwHi0-afY/edit?usp=sharing).
     If you can not access the Google Doc, please send an email to Alexis Perry-Holby at [e-mail] requesting to be added to the access list.
--   Minutes from older meetings were sent to [flang-dev](http://lists.llvm.org/mailman/listinfo/flang-dev). Search for `Flang Biweekly Sync - Notes`.
+-   Minutes from older meetings were posted on the [Flang forum](https://discourse.llvm.org/c/subprojects/flang). Search for `Flang Biweekly Sync - Notes`.
 
 ### Flang Community Technical Biweekly Call
 
 -   Technical topics call.
 -   Join [Flang Community Technical Biweekly Call](https://bluejeans.com/284530575)
 -   Time: On Mondays 8:30 Pacific Time, on the weeks alternating with regular Flang Community Biweekly Call.
 -   The agenda is in this [Google Doc](https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/).
 

libcxx/docs/index.rst

 
 First please review our `Developer's Policy <https://llvm.org/docs/DeveloperPolicy.html>`__
 and `Getting started with LLVM <https://llvm.org/docs/GettingStarted.html>`__.
 
 **Bug Reports**
 
 If you think you've found a bug in libc++, please report it using
 the `LLVM bug tracker`_. If you're not sure, you
-can post a message to the `libcxx-dev mailing list`_ or on IRC.
+can ask for support on the `libcxx forum`_ or on IRC.
 
 **Patches**
 
 If you want to contribute a patch to libc++, the best place for that is
 `Phabricator <https://llvm.org/docs/Phabricator.html>`_. Please add `libcxx-commits` as a subscriber.
-Also make sure you are subscribed to the `libcxx-commits mailing list <http://lists.llvm.org/mailman/listinfo/libcxx-commits>`_.
+Also make sure you are subscribed to the `libcxx-commits mailing list`_.
 
 **Discussion and Questions**
 
-Send discussions and questions to the
-`libcxx-dev mailing list <http://lists.llvm.org/mailman/listinfo/libcxx-dev>`_.
+Send discussions and questions to the `libcxx forum`_.
 
 
 Quick Links
 ===========
 * `LLVM Homepage <https://llvm.org/>`_
 * `libc++abi Homepage <http://libcxxabi.llvm.org/>`_
-* `LLVM bug tracker <https://github.com/llvm/llvm-project/labels/libc++/>`_
-* `libcxx-commits Mailing List`_
-* `libcxx-dev Mailing List`_
+* `LLVM Bug Tracker <https://github.com/llvm/llvm-project/labels/libc++/>`_
+* `libcxx-commits Mailing List <http://lists.llvm.org/mailman/listinfo/libcxx-commits>`_
+* `libcxx Forum <https://discourse.llvm.org/c/runtimes/libcxx/>`_
 * `Browse libc++ Sources <https://github.com/llvm/llvm-project/tree/main/libcxx/>`_

libunwind/docs/index.rst

 
 First please review our `Developer's Policy <https://llvm.org/docs/DeveloperPolicy.html>`__
 and `Getting started with LLVM <https://llvm.org/docs/GettingStarted.html>`__.
 
 **Bug Reports**
 
 If you think you've found a bug in libunwind, please report it using
 the `LLVM bug tracker`_. If you're not sure, you
-can post a message to the `cfe-dev mailing list`_ or on IRC.
-Please include "libunwind" in your subject.
+can ask for support on the `Runtimes forum`_ or on IRC.
+Please use the tag "libunwind" for new threads.
 
 **Patches**
 
 If you want to contribute a patch to libunwind, the best place for that is
 `Phabricator <https://llvm.org/docs/Phabricator.html>`_. Please include [libunwind] in the subject and
-add `cfe-commits` as a subscriber. Also make sure you are subscribed to the
-`cfe-commits mailing list <http://lists.llvm.org/mailman/listinfo/cfe-commits>`_.
+add `cfe-commits` as a subscriber. Also make sure you are subscribed to the `cfe-commits mailing list`_.
 
 **Discussion and Questions**
 
-Send discussions and questions to the
-`cfe-dev mailing list <http://lists.llvm.org/mailman/listinfo/cfe-dev>`_.
-Please include [libunwind] in the subject.
+Send discussions and questions to the `Runtimes forum`_. Please add the tag "libunwind" to your post.
 
 
 Quick Links
 ===========
 * `LLVM Homepage <https://llvm.org/>`_
-* `LLVM bug tracker <https://github.com/llvm/llvm-project/labels/libunwind/>`_
-* `cfe-commits Mailing List`_
-* `cfe-dev Mailing List`_
+* `LLVM Bug Tracker <https://github.com/llvm/llvm-project/labels/libunwind/>`_
+* `cfe-dev Mailing List <http://lists.llvm.org/mailman/listinfo/cfe-dev>`_
+* `cfe-commits Mailing List <http://lists.llvm.org/mailman/listinfo/cfe-commits>`_
+* `Runtimes Forum <https://discourse.llvm.org/tags/c/runtimes>`_
 * `Browse libunwind Sources <https://github.com/llvm/llvm-project/blob/main/libunwind/>`_

lldb/docs/index.rst

 
 * on macOS with a :ref:`generated Xcode project <CMakeGeneratedXcodeProject>`
 * on Linux and FreeBSD with Clang and libstdc++/libc++
 * on NetBSD with GCC/Clang and libstdc++/libc++
 * on Windows with a generated project for VS 2017 or higher
 
 See the :doc:`LLDB Build Page <resources/build>` for build instructions.
 
-Discussions about LLDB should go to the `lldb-dev
-<http://lists.llvm.org/mailman/listinfo/lldb-dev>`__ mailing list. Commit
+Discussions about LLDB should go to the `LLDB forum
+<https://discourse.llvm.org/c/subprojects/lldb>`__. Commit
 messages are automatically sent to the `lldb-commits
-<http://lists.llvm.org/mailman/listinfo/lldb-commits>`__ mailing list , and
+<http://lists.llvm.org/mailman/listinfo/lldb-commits>`__ mailing list, and
 this is also the preferred mailing list for patch submissions.
 
 See the :doc:`Projects page <status/projects>` if you are looking for some
 interesting areas to contribute to lldb.
 
 .. toctree::
    :hidden:
    :maxdepth: 1

llvm/docs/Contributing.rst

`LLVM for Grad Students`__
 
   .. __: http://www.cs.cornell.edu/~asampson/blog/llvm.html
 
 `Intro to LLVM`__
   Book chapter providing a compiler hacker's introduction to LLVM.
 
   .. __: http://www.aosabook.org/en/llvm.html
 
-.. _Developer's List (llvm-dev): http://lists.llvm.org/mailman/listinfo/llvm-dev
+.. _Forum: https://discourse.llvm.org
 .. _irc.oftc.net: irc://irc.oftc.net/llvm
 .. _beginner: https://github.com/llvm/llvm-project/issues?q=is%3Aopen+is%3Aissue+label%3Abeginner
 .. _bug tracker: https://github.com/llvm/llvm-project/issues
 .. _clang-format-diff.py: https://reviews.llvm.org/source/llvm-github/browse/main/clang/tools/clang-format/clang-format-diff.py
 .. _git-clang-format: https://reviews.llvm.org/source/llvm-github/browse/main/clang/tools/clang-format/git-clang-format
 .. _LLVM's Phabricator: https://reviews.llvm.org/
 .. _LLVM's Open Projects page: https://llvm.org/OpenProjects.html#what
-.. _LLVM Developer's mailing list: http://lists.llvm.org/mailman/listinfo/llvm-dev

llvm/docs/ExtendingLLVM.rst

 ============================================================
 Extending LLVM: Adding instructions, intrinsics, types, etc.
 ============================================================
 
 Introduction and Warning
 ========================
 
 
 During the course of using LLVM, you may wish to customize it for your research
 project or for experimentation. At this point, you may realize that you need to
 add something to LLVM, whether it be a new fundamental type, a new intrinsic
 function, or a whole new instruction.
 
 When you come to this realization, stop and think. Do you really need to extend
 LLVM? Is it a new fundamental capability that LLVM does not support at its
 current incarnation or can it be synthesized from already pre-existing LLVM
-elements? If you are not sure, ask on the `LLVM-dev
-<http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ list. The reason is that
+elements? If you are not sure, ask on the `LLVM forums
+<https://discourse.llvm.org>`_. The reason is that
 extending LLVM will get involved as you need to update all the different passes
 that you intend to use with your extension, and there are ``many`` LLVM analyses
 and transformations, so it may be quite a bit of work.
 
 Adding an `intrinsic function`_ is far easier than adding an
 instruction, and is transparent to optimization passes.  If your added
 functionality can be expressed as a function call, an intrinsic function is the
 method of choice for LLVM extension.
 

llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst

-  **unusual domains** - We've been talking about applying LLVM to a
    compiler technology that are not typically considered. For example,
    LLVM has been used to implement OpenGL graphics acceleration,
    translate C++ code to ActionScript, and many other cute and clever
    things. Maybe you will be the first to JIT compile a regular
    expression interpreter into native code with LLVM?
 
 Have fun - try doing something crazy and unusual. Building a language
 like everyone else always has, is much less fun than trying something a
 little crazy or off the wall and seeing how it turns out. If you get
-stuck or want to talk about it, feel free to email the `llvm-dev mailing
-list <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_: it has lots
-of people who are interested in languages and are often willing to help
-out.
+stuck or want to talk about it, please post on the `LLVM forums 
+<https://discourse.llvm.org>`_: it has lots of people who are interested
+in languages and are often willing to help out.
 
 Before we end this tutorial, I want to talk about some "tips and tricks"
 for generating LLVM IR. These are some of the more subtle things that
 may not be obvious, but are very useful if you want to take advantage of
 LLVM's capabilities.
 
 Properties of the LLVM IR
 =========================

 process (assuming the JVM has no bugs). Safety is an interesting
 property that requires a combination of language design, runtime
 support, and often operating system support.
 
 It is certainly possible to implement a safe language in LLVM, but LLVM
 IR does not itself guarantee safety. The LLVM IR allows unsafe pointer
 casts, use after free bugs, buffer over-runs, and a variety of other
 problems. Safety needs to be implemented as a layer on top of LLVM and,
-conveniently, several groups have investigated this. Ask on the `llvm-dev
-mailing list <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ if
-you are interested in more details.
+conveniently, several groups have investigated this. Ask on the `LLVM
+forums <https://discourse.llvm.org>`_ if you are interested in more details.
 
 Language-Specific Optimizations
 -------------------------------
 
 One thing about LLVM that turns off many people is that it does not
 solve all the world's problems in one system.  One specific
 complaint is that people perceive LLVM as being incapable of performing
 high-level language-specific optimization: LLVM "loses too much