[RFC] Decide officially supported/tested platform

[YJDoc2]

This issue originates from this and this. Particularly the comment

Here is what I propose. We declare that Ubuntu and Fedora are the official dev environment we support. We will create automation for setting up the environment for these two OS. Eventually, we would even make CI a matrix strategy running both Ubuntu and Fedora.

Given that this would be a big commitment as well as a big decision as a project, opening this RFC for discussion.

Note that this was already once considered in #39 and in even more detail in #369.

@containers/youki-maintainers Please feel free to share your views and opinions on this :)

[YJDoc2]

My view regarding this is :

• Let us use the tier based support model similar to Rust, and decide what OS/arch goes into which tier and what amount of support each tier gets.
• I think ubuntu, fedora and some RHL based distro should have maximum support (tier 1) as all of these are pretty wide spread, and should cover a considerable amount of users
• We can declare alpine linux as tier 2 (?)
• We have to support x86_64 as tier 1 , and possibly arm / RISC V (?) as tier 2+

As for deciding what tiers actually mean :

• Tier 1 support can mean we validate building and test suites pass for each master merge. We can also split it as : for each PR, first only run Ubuntu CI, and before merging run the whole matrix. This would allow good tradeoff between amount of CI runs for each commit and running tests for all supported stuff.
• Tier 2 support can mean that youki will build (all features ?) for that but not necessary all tests will be run / pass. We can only run unit tests and not run integration tests etc.
• Tier 3 means youki will build, but we will not be running any tests at all. (Just the guarantee that the compilation of youki will succeed given correct external dependencies are installed eg seccomp etc.)

As from this, this, this and this ; having arm support even for building can be difficult, but we should do an exploratory PR none the less to see what actually happens if we decide to go ahead with this.

Another note is that if we do decide to go in some similar direction to this, we might need to strengthen out CI to support these many runs and matrix run efficiently. This includes running only a subset of stuff on each commit in PR, and having a way to run everything before merge etc.

[utam0k]

I consider the cost of managing these to be high. And I do not think there is any part of Linux distros that makes a difference.
I want to support architectures other than x86, but I don't realistically have a CI to run them.
Would anyone actually benefit from doing this tier? I fear these will be a strong drag on the maintainer. We do not want to strangle ourselves.

[yihuaf]

I agree with @utam0k that the cost to maintain many distro/targets can be high. The project is best served to focus one, at most two platforms/distros/targets and build youki to be rock solid. Today, the only implicit "official" support we declare is Ubuntu x86 and kernel version >= 5.3, since we run CI tests on this target. We also do provide instructions for fedora and family, but we don't actively test them in CI. I mention fedora here only because it is one of the easiest way to run kernel that is closer to the bleeding edge, and it is likely the 2nd most popular dev platform in the wild. At the same time, github CI doesn't support fedora last time I checked.

For all other platforms and architectures, I would default to "Not for Now".

[yihuaf]

Oh, and in addition to platform, we may also want to support musl as a build target. There are two usecases:

1. statically linked youki binary. (libseccomp and libdbus is a blocker, but can be work around by compiling in alpine)
2. projects using libcontainer such as aurae, whose maintainer implemented the first musl support for us.