Broken links in PMIx Standard Version 2.0

[cniethammer]

The PMIx Standard Version 2 (2018) references several pages on pmix.org.
All those links seem to be broken at the moment:

  - https://pmix.org/support/faq/what-apis-are-supported-on-my-rm/ (page 16)
  - https://pmix.org/code/getting-the-pmix-reference-server/ (page 16)
  - https://pmix.org/code/getting-the-reference-implementation/ (page 16)
  - https://pmix.org/support/faq/wildcard-rank-access/ (page 107)

Unfortunately, I could not find corresponding pages on the pmix.github.io pages to suggest as simple replacements.

[jjhursey]

Thanks for spotting those! When we moved things to GitHub Pages I bet things were lost. We will work on updating the standard and providing redirections to the appropriate places. For now I'm going to assign the @pmix/asc-secretaries to this task.

Since those were in version 2, we might post an errata. But we should check the later versions to make sure they do not have the same issue.

[jjhursey]

@pmix/asc-secretaries Can you check on these links?

[naughtont3]

These are links to what now (should) live at openpmix.org/support/faq. I'll look there to nail down the corresponding files. For example, I think the first FAQ mentioned from page16 would correspond to: https://openpmix.github.io/support/faq/what-apis-are-supported-on-my-rm

[naughtont3]

Not sure how exactly we want to handle the errata but for the specific links here are the "NOW" versions of things...

• https://pmix.org/support/faq/what-apis-are-supported-on-my-rm/ (page 16)

  • NOW: https://openpmix.github.io/support/faq/what-apis-are-supported-on-my-rm

• https://pmix.org/code/getting-the-pmix-reference-server/ (page 16)

  • NOW: https://openpmix.github.io/code/getting-the-pmix-reference-server

• https://pmix.org/code/getting-the-reference-implementation/ (page 16)

  • NOW: https://openpmix.github.io/code/getting-the-reference-implementation

• https://pmix.org/support/faq/wildcard-rank-access/ (page 107)

  • NOW: https://openpmix.org/support/faq/rm-provided-information/

[rhc54]

Hmmm...my guess is that many of those links and references need to be removed from the Standard. It's a tad murky - the references to what is supported by various RMs and libraries are implementation-agnostic, and one could argue that is appropriate to track with the Standard. If so, you should probably move those pages to the PMIx site.

Things about getting the reference implementation probably don't belong as it implies some special status for that implementation.

PRRTE is a tougher call as it can support any PMIx implementation that meets its requirements. Not sure how you want to handle that one. It resides in the OpenPMIx project area, which further complicates things - but let's not even think of moving it to some other project now.

[naughtont3]

Yes, I tend to agree. We should discuss how we want to handle these types of errata in general. The latest v4 spec did not have these issues as we had already started the pmix-standard/openpmix separation.

We might want to just have a general errata for past versions of the spec. I made the changes to past specs branches mainly to see what the changes look like but as I was making the changes it started to feel a bit wrong.

[jjhursey]

@naughtont3 Did file these two PRs:

• v3 : errata: fix broken links in spec v3 #431
• v2 : errata: fix broken links in spec v2 #432
• v4, v5/main do not seem to be impacted (is that accurate)?

Since v3 and v2 are no longer being updated my inclination is to do the following:

• Commit the PRs to those branches
• Do not roll a new release. Git has the updates if we need to reconsider this in the future

What do people think?

[jjhursey]

Can we reach a resolution on this issue so we can decide what todo with #431 and #432. I'll add it as a discussion item for the ASC meeting in a couple of weeks

[abouteiller]

From our prior discussions, I understood that our group plan would

1. commit the corrections to v2 and v3 documents on GitHub
2. re-publish the corrected documents on pmix.org without introducing a new standard version number

But there is the issue of the GitHub release page and tags. It is impossible to 'hot swap' the pmix-3.1 document on the GitHub release page without rewriting the git tags and re-publising the same release. I am not very excited about rewriting the GitHub history.

On the other hand, having the github release and the document obtained from pmix.org be different is problematic as well.

Hence I join Josh in recommending that we do not republish v2 or v3 at all, and just update the branches without further action.