What should the relationship between ports and developers of large projects be?

[Thomas Stüfe]

On Fri, May 27, 2022 at 9:34 PM Jesper Wilhelmsson <
jesper.wilhelmsson at oracle.com> wrote:

> > On 27 May 2022, at 18:28, Andrew Haley <aph-open at littlepinkcloud.com>
> wrote:
> >
> > On 5/27/22 15:05, Andrew Haley wrote:
> >
> >> So, it's going to be something of a rush. I hope that JDK 19 won't be
> >> blighted by broken or absent ports because of this. This would be a
> >> great shame.
> >
> > I see that Alan Bateman just posted in
> https://github.com/openjdk/jdk/pull/8919
> > that there will hopefully soon be an alternative implementation of
> virtual
> > threads backed by platform threads, that allows ports to pass conformance
> > tests, although the result clearly won't scale like real virtual threads
> do.
> >
> > The rest of my message about communicating with porters still stands, I
> think.
>
> A good start would be a list of contacts for each port. Is there any such
> list and is it kept up to date?
> Or would it be enough for a project lead of a soon to be integrated
> project to send an email to the porters-dev list and assume that all active
> ports are represented there?
>
> /Jesper
>
>
Yes, a list of contacts would help. E.g. I am not sure who maintains the
various BSDs. The list could also contain special configurations like Zero
or Alpine. Is there a common understanding about which platforms are "first
tier"?

When finishing a large feature, it can help to have a few online meetings
in addition to ML discussions. Some people find it easier to speak than
write. Especially if a feature is developed within one organization, where
a lot of information flows internally. For JEP387 we had such meetings in
the review phase, and they worked quite well.

Stating the obvious, it helps if large patches were split up into
smaller ones. The loom patch brought my browser to its knees. For that,
maybe lower the bar for introducing patches whose sole purpose is to
prepare a larger integration or make merging side projects with mainline
easier. I had preparatory patches like these rejected in the past,
understandingly, on the ground that they had no merit on their own.

Since porters are very few, it can be helpful to be able to delay
start porting until the dust has settled and the kinks worked out. For
that, a feature would have to be switchable. But I understand that is
not always possible.

Thanks, Thomas