Clarification regarding the GitHub Actions pre-submit testing
aph at redhat.com
Fri Mar 19 10:00:16 UTC 2021
On 3/18/21 10:20 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"  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)?
Perhaps. In that case all a contributor has to do is send a mail to
porters-dev saying "This patch may break your port." That doesn't even
need to scale out because porters-dev reaches maintainers of all ports.
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the jdk-dev