Clarification regarding the GitHub Actions pre-submit testing

[Severin Gehwolf]

On Thu, 2021-03-18 at 18:31 +0000, Andrew Haley wrote:
> 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.

+1

> 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.

That sounds very reasonable to me. I'm convinced a best effort approach
like this would already go a long way.

Thanks,
Severin