JDK Updates Project Page

[Andrew Hughes]

On 15 November 2017 at 12:02, Mario Torre <neugens at redhat.com> wrote:
> On Tue, Nov 14, 2017 at 7:47 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
>> My worry with moving away from the mailing list approach is it
>> decreases the transparency
>> even more. Now only those monitoring the bug will see what's going on.
>> It's also worth noting
>> that not everyone who posts to the update mailing lists has access to
>> the OpenJDK bug database.
>> I've filed bugs and pushed fixes on behalf of others before.
>
> I actually suggested that to have an all in one place discussion, but
> Rob mentioned what you say too, that only people with bug database
> access would be able to participate in the discussion, which is
> obviously a no-go, the discussion needs to stay open, hence on the
> mailing list.
>
> I think the rules as they stand are pretty ok, for LTS we will need
> different rules but limiting critical bugs to the short term updates
> makes sense. We only need to ensure that we can rise bugs to P1 for
> platforms that are not Oracle main interest, like AArch64 or PPC as
> you mention or for issues that are not marked as critical by Oracle
> but are for a given 3rd party. With the short term release, though,
> keeping a number of patches in downstream builds may be practical to
> sustain - considering that we are talking about back ports, those
> fixes will be in upstream repositories already.
>

A few patches is inevitable with any project, due to different timelines.
The problem with 8u122/152 was that, for example, a fix for GCC 6 I pushed
upstream last summer was still not in an upstream release this summer.

I think a lot may change as Oracle actually start working on OpenJDK as
their release and not a proprietary fork. A lot of my current issues probably
stem from this us-vs-them situation where it feels like we're requesting a
fix be added to *their* release of *their* JDK, not OpenJDK. These aren't
technical issues, but a way of thinking about releases that needs to change.

> I wonder if it isn't best to have this conversation again after the 9
> and perhaps 10 versions will be EOL to see what is getting accumulated
> in downstream builds and see if we need a process change to limit the
> differences. Other than that, I don't see much of a problem, releases
> are only 6 months away each other, if for some reason 9 is EOLed by
> Oracle but, just as an example, Red Hat or SAP wants to keep
> maintaining it, this is the same process as we already do now for 6, 7
> and eventually 8, at the take over patches can be merged into the main
> repository and back ported as newer versions go on for as long as this
> is needed.
>
> Again, the weak link where I expect that to actually happen is the
> LTS, but this will need a separate set of rules, as we all seem to
> agree anyway.
>
> All that said, you are clearly the most authoritative person regarding
> back ports issues, if you think something should be changed to
> facilitate the work with short term releases I think your feedback is
> really important to have.

We will have to see how things progress and what demand there is
for various versions. So much is changing that it's hard to know what
is best at this point, so the main thing is not to set too much in stone.

Based on past experience, I think it's more likely that there will be a
demand for LTS releases beyond three years, than for extension of a release
that has only been adopted by keen developers wanting the latest and greatest.
But unrewarding work like this is based on who will pay for it to be done,
so ultimately it depends on these stakeholders.

>
> Cheers,
> Mario

Cheers,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222