Clarification regarding the GitHub Actions pre-submit testing

[Aleksey Shipilev]

On 3/18/21 5:51 PM, Andrew Haley wrote:
> On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
>> Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from
>> the shared code. As I said before, it is a fair game for non-mainline development to hack the
>> prototypes any way they want, including focusing only on one platform at a time. But if we decide to
>> integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable,
>> and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That
>> is, GHA would be a very basic quality gate working as intended.
> 
> The question is this: on whom does the buildability requirement rest?

I believe pre-integration testing, including buildability checks, always rests on contributor, 
unless reviewers agree the usual rules can be relaxed. What constitutes "usual rules" with regards 
to builds/tests is codifiable into mechanical checks. GHA seems to be as good vehicle for this 
codification. So...

> If we are to allow many ports into OpenJDK, and I believe we should,
> then the burden of even stubbing things out to make sure that all
> weird ports work is intolerable for contributors. It can not scale.

...that feeds into question which ports do we accept to GHA.

"Weird ports" [1] should not be the part of it. Current list includes all actively maintained 
mainline ports: x86_64, x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not only we have 
active maintainers, but we also have build instructions in OpenJDK docs, not to mention the GHA 
workflow script itself.

-- 
Thanks,
-Aleksey

[1] At this point, they seem to be: armel, m68k, mips64el, mipsel, ppc, ppc64be, sh4, 
windows-x86_32, etc. These are not and should not be the part of pre-integration testing.