Document supported platforms #1431
Conversation
We add a section in README.md and mention the level of support we provide for each platform (target triple) in a similar way the Rust project defines "tiers". Closes: mmtk#1430
|
MMTk ART also supports |
|
|
||
| - Tier 1 platforms are guaranteed to work. We do CI tests with the MMTk core and at least one binding. | ||
| - Tier 2 platforms are guaranteed to build. We do CI tests with the MMTk core. | ||
| - Tier 3 platforms have support in the mmtk-core code base, but we make no guarantee whether they will build or work. |
There was a problem hiding this comment.
After more thoughts on this, I think we could just adopt Rust's tiers: T1 = 'guarantee to work' (not requiring at least one binding), T2 = 'guarantee to build' (not requiring pass CI tests), T3 = 'we have support, but no guarantee'.
Currently there is inconsistency in the current tier 2 definition: 'guarantee to build', and 'pass CI tests'. Those are two different things. Rust's T2 allows tests to fail. In the future, we will expect mmtk-core's unit tests to be more complex, as seen in #1408. I would expect 'passing tests' to be closer to 'guarantee to work' (instead of 'guarantee to build').
We may change the tier for a platform in the future, but we don't generally want to change the definition of tiers. Having 'at least one binding' is important for now, but it may become less important in the future when we have more unit tests for MMTk core, and what one binding may test eventually may become a strict subset of what our unit tests cover in MMTk core. Consider two cases. For OpenJDK, we already knew that it only tests the default space and the large object space. Eventually when we have more complex unit tests, we would expect passing CI tests to be more credible than having one binding. For JikesRVM, it only includes a subset of MMTk GC plans. I don't really feel it gives us more confidence in the platform than what the current unit testing delivers. Plus, porting MMTk core to a new platform (especially to a different architecture) should be easier than porting a binding to a new platform. We may have a platform that we could pass all the tests with good code coverage, but we don't have a real binding that targets it. Do we still put the platform as T2 because we don't have a binding to work on it (even if the unit tests may already have more coverage)?
If we really want to show the importance of having a real binding for the platform, we could add a T0 on top of T1/2/3 (which are the same as Rust's tiers): T0 requires at least one binding. In this case, T0 highlights the existence of a real binding being tested with the platform, but T1 also means we expect MMTk to work on the platform.
There was a problem hiding this comment.
I removed CI and bindings from the definition of tiers. I think that should be enough for the user, and we leave some room for us to change our CI policy as we need.
| | riscv64gc-unknown-linux-gnu | 2 | 3 | (4) | | ||
| | aarch64-linux-android | 2 | 3 | (5) | | ||
|
|
||
| Notes: |
There was a problem hiding this comment.
I think we can remove the notes from README.md to keep README succinct. The notes are basically the reasons why we put them in this tier, and we only need to let users know the tiers (rather than the reasons). We can create another doc docs/team/tiers.md for these notes with a link in README.md
There was a problem hiding this comment.
I removed all notes except the one for x86_64-apple-darwin. It tells the user that x86_64-apple-darwin may be replaced in the future.
Add x86_64-linux-android No longer mention CI in the definition of tiers. Remove all notes except one.
Yes. I added that to the table. |
3 participants
We add a section in README.md and mention the level of support we provide for each platform (target triple) in a similar way the Rust project defines "tiers".
Closes: #1430