Clarification regarding the GitHub Actions pre-submit testing

[Thomas Stüfe]

On Thu, Mar 18, 2021 at 11:21 PM <mark.reinhold at oracle.com> wrote:

> 2021/3/18 11:31:25 -0700, Andrew Haley <aph at redhat.com>:
> > On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
> >> On 3/18/21 5:51 PM, Andrew Haley wrote:
> >>> ...
> >>>
> >>> 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.
>
> Two questions:
>
>   (1) If weird ports are included in GHA testing then doesn’t that leave
>       contributors with the intolerable burden of stubbing things out in
>       a way that does not scale, as you wrote earlier (see above)?
>
>
Large projects like Valhalla or Panama aside, I don't believe this is such
a harsh requirement. The vast majority of everyday fixes are platform
independent. We use a very small range of compilers (gcc, VC++, clang) so
compiler-specific issues show seldom up on just one platform only. In my
experience single-platform breakages are not that frequent. And as was
stated before are usually trivial to fix, e.g. missing includes.

Requiring build cleanliness on multiple platforms is also also a good
incentive to clean out platform dependencies. For example, a lot of work
was done recently to move unify platform-specific coding into the general
Posix layer. This improves long term maintainability. We will continue
reducing platform dependent coding this way.

  (2) If the fix is non-trivial and the committer is obliged to contact
>       the port maintainer to explain the situation, what is it that you
>       expect to happen before X days pass?  Is the committer supposed to
>       wait for at most X days for the port maintainer to provide a fix?
>
>
The port maintainer would get a short time to fix the breakage. To propose
a patch atop of that patch. I believe the maintainer could even commit
directly into the PR, though I am not sure if that works.
If the maintainer does not react, it would be fine to push the change.


> > 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.
>
> A laudable goal, I agree.
>
> I’d like to hear from other contributors on this -- especially those who
> work on code that often requires architecture- or OS-specific porting
> (e.g., HotSpot, core libraries).
>
> - Mark
>

As for larger projects, Maurizio brought up the point of diverging feature
sets for different architectures. While this is valid, I think of this as
the lesser of two evils. Better have a VM which has the core functionality
expected from a VM, but maybe misses Shenandoah or Z or Panama, then to
have no implementation at all. Also, we have been in this place for years
already.

We want all the same, no? A broad adoption of java, lots of talent which
will come to use the language in the future, and a high quality VM. For all
that, platform breadth is important. The weird niches where the tinkerers
roam are important. E.g. I believe the fact that Java runs on a 32bit
Raspberry Pi is really a good thing. That is why I also like Zero, since it
is the bridgehead into new platforms. Beside giving Debian a VM to run on
almost all of its variants. I was happy to see Zero in GHAs.

About quality. Different compilers find different errors. I think both
32bit- and big-endian-cleanliness affect overall quality in a good way.
Bugs catched via those routes can also impact mainline architectures. I
realize that big-endian-cleanliness is probably a lost battle. But it is
really simple to build 32bit nowadays. E.g. The multiarch support on Debian
distros is excellent. Therefore I would like to see 32bit (linux x86) as a
primary platform. Not only is it simple to build, but as Alexey wrote, it
also benefits a whole range of other 32bit platforms.

Thanks, Thomas