Clarification regarding the GitHub Actions pre-submit testing

[mark.reinhold at oracle.com]

2021/3/17 7:49:23 -0700, alan.bateman at oracle.com:
> On 17/03/2021 13:43, Aleksey Shipilev wrote:
>> :
>> 
>> Technically speaking, in the last few months we saw issues that 
>> slipped through Oracle's build-test system. Arch-specific build 
>> breakages were caught by GHA. Not sure if Oracle systems run any 
>> 32-bit tests, so 32-bit build/test failures were caught. There were 
>> issues when a minor post-internal-testing fix actually broke the code, 
>> and it was caught by GHA, which runs on every sync.
> 
> The topic of ports and maintainers has come up a few times at the 
> OpenJDK Committers Workshop. At least some of us had hoped it would lead 
> to some agreement on the ports that are required to build at all times, 
> and/or a maintainers file that name the people responsible for keeping 
> specific ports and features alive.
> 
> For the most part it has defined itself. If a change causes breakage on 
> linux-x64, windows-x64, macosx-x64 or linux-aarch64 then it is 
> disruptive to a lot of people and needs urgent attention, at least when 
> it breaks with versions of a toolchain that are widely used. On the 
> other hand, breakage to ports such as linux-s390 or aix-ppc64 doesn't 
> impact too many people and can be fixed up later (the SAP engineers seem 
> to work tirelessly to keep these ports going).
> 
> I'm not aware of any recent discussion/agreement on the 32-bit ports. 
> Oracle engineers haven't been building the main line on 32-bit for 
> several years (I think JDK 8 was the last) so periodic/temporary 
> breakage isn't too surprising. I don't know when 32-bit was added to the 
> GitHub Actions but requiring all changes to be build/tested on 32-bit 
> would need discussion. I'm thinking specifically of some of the bigger 
> OpenJDK projects that will involving non-trivial porting and whether 
> they will now be required to have 32-bit ports completed before integrating.

As Alan’s summary suggests, in practice we already have two categories
of ports -- we just don’t have names for them.

  - _Primary ports_ (for lack of a better term) are the most broadly
    used.  They can be built and tested on hardware and software
    platforms that are commonly available.

    Examples of primary ports: linux-{x64,aarch64}, windows-x64, macosx-x64

    If the build or testing of a primary port breaks in the main line
    then those responsible for the change generally scramble to fix it.
    A change that requires porting work cannot be integrated into the
    main line until it supports all of the primary ports.

  - _Secondary ports_ (again, for lack of a better term) are less
    broadly used, though they are important to some developers and
    companies.  Building them often requires hardware and software
    platforms that are not commonly available.

    Examples of secondary ports: linux-{arm,ppc64,s390}, aix-ppc64

    If the build or testing of a secondary port breaks in the main line
    then those who maintain that port generally fix it.  A change that
    requires porting work can be integrated into the main line without
    supporting the secondary ports, but contributors of such changes are
    encouraged to assist the maintainers of the secondary ports in doing
    the necessary porting work.

Assuming that we agree on this story so far, where does that leave the
32-bit ports presently tested in GitHub actions?  Primary, or secondary?

Where does that leave windows-aarch64, and the forthcoming macos-aarch64?

Must Valhalla’s JEP 401 (Primitive Objects) support windows-aarch64,
macos-aarch64, linux-{arm,ppc64,s390}, and aix-ppc64 before it’s
integrated?

- Mark