Clarification regarding the GitHub Actions pre-submit testing

[Andrew Haley]

On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
> 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.

For avoidance of doubt, I'm very much in favour of GHA testing and
think there should be more of it, and weird ports may be included.
Information is good.

Here's how I think it could work. If there is an obvious/trivial
fix revealed by GHA testing, the committer should fix it,
Otherwise, it should be fixed by the port maintainer. In the
latter case, the committer should try to contact the port
maintainer to explain the situation. The committer isn't required
to wait for longer than X days.

That's a best effort way we can all work together, doesn't impose
undue burdens on either committers or port maintainers, and we
should all be happy to do as good citizens.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671