toolkit: supported platforms: note that things may work on other/newer distros

[jgehrcke]

I was reading through the discussion in #62 and found it very tangible. Instead of iterating on the PR I thought I create a new one with my proposal to address some of the points discussed there.

I very much agree with @elezar that we need a note about those distributions that are not listed in that table, and that we want to invite people to just try things out. This is the main part of this patch.

Additional changes:

• Centos -> CentOS
• Instead of loading lots of meaning into a single word: "supported" vs "qualified" I propose using slightly more exhaustive wording: "qualification-tested and expected to work on these platforms"
• We did use footnotes, and I have changed one note about Tegra into a footnote.

[elezar]

I think I'm happy with the changes.

@a-mccarthy any further comments?

[a-mccarthy]

Maybe lets put this in its own section? or as some paragraphs after the table. Otherwise the footnotes get pushed down further and we have a bit of note inception going on, notes within notes.

Maybe something like "Using unsupported distros" or "Distribution testing" or "Additional distros" for a section heading. Then we can go into details on the qualification testing done and your note on using unsupported distros how to give us feedback?

[jgehrcke]

Maybe lets put this in its own section? or as some paragraphs after the table.

Yes, I like that you say this. Thought about it too, was looking for feedback about this in particular.

I will add sub sections, one about reporting issues in general, and one about "Other Linux distributions".

[a-mccarthy]

I'm not sure what qualification-testing means. Is it generic enough that readers would know what it means? Are there qualifications that we test that are specific to the software that we can link to?

I'd be a little cautious with removing the word "support" entirely here. B/c I don't want this to read like "we support everything, everywhere, all the time". Is there an SLA on support and what the community can reasonably expect in terms of getting questions answered for unsupported use cases?

[jgehrcke]

I'm not sure what qualification-testing means.

Qualification-testing in my experience in software engineering typically refers to a quality assurance stage as part of a release process, trying to make (pretty damn) sure that things really work (this is testing done in addition to, say, CI tests).

Other than that, I allow myself to make a bit of a joke here and refer to NASA:

I think you inspire me to simplify. I will remove the "qualification-". Simplicity wins, so I will push a commit changing this to:

Releases are tested and expected to work on these platforms

[a-mccarthy]

@jgehrcke thanks for the PR! I think its great to encourage the community to try out stuff and give us feedback. It feels like 2 separate concerns here though.

1. List what is supported and what users can expect to be supported to get questions answered if they run into issues
2. Letting folks know a bit about the testing and that things should work on other distros if they want to experiment or have a need to use something not on the official list

I added a few comments about this inline as well, but I'm thinking it might be best to have your additions in their own section. Just my 2 cents, I'm not overly familiar with the testing and support matrix in depth though, so i might not be thinking about things the same as you all :)

[jgehrcke]

I pushed an update. This is how this currently renders in my VSCode:

[github-actions]

Documentation preview

https://nvidia.github.io/cloud-native-docs/review/pr-159

[jgehrcke]

conflicting with #152

[jgehrcke]

Merge conflict resolved, squashed into single commit, worked on commit msg (trying to summarize changes).

[jgehrcke]

Going ahead here, we can always discuss and iterate more post-merge. Thanks for feedback, everyone.