JDK Updates Project Page

[Phil Race]

On 11/09/2017 03:50 AM, Mario Torre wrote:
> Hi Rob,
>
> I went through the documents, and I have a couple of comments/questions.
>
> The document is simple enough to understand even for me, so that's a
> good signal, I would personally put everything in a single page
> though.

+1 to that.
The back and forth navigation is too much overhead for the small amount 
of content on each page.

> Since this is a process, a diagram of the actions rather than
> a list of rules may be even easier to understand, with the benefit of
> indicating exactly who is responsible for what at any given step (the
> need, for example, to involve the original reviewers/contributors of
> the patch, is that a requirement for each backport or just a
> suggestion? I believe than as much as possible, the original authors
> should be involved again in the process, the only case where this
> doesn't apply is either of them is not available, in this case is the
> Lead call to request info).
>
> You mention that you need to label the corresponding master/parent
> issue with the <release>-critical-request tag, it's not clear to me if
> this is something we need to do after the bug has been reviewed for
> backport, in which case it seems redundant, or if it's a pre-requisite
> for the review step to even begin (which means that the "Public Code
> Review" process is parallel to the "Requesting push approval for
> fixes").
>
> It's not clear to me why a backport request needs to be critical to be
> approved. A backport may not be critical, but still more than just a
> nice to have feature that warrant the code change. For example, the
> bug I submitted (which from now on will be our test case!), is not
> exactly critical, but it's clearly something that touches many users
> especially in a server like environment with a limited install base,
> which qualifies it to be more than just "nice to have". In fact, the
> list of critical bugs mention P1, while this bug is P4. It's not a
> regression either, strictly speaking, since it's about installed fonts
> on the system.

Mario, I think the issue here is that the only planned update releases 
for JDK 9 and JDK 10
are CPU releases. That's the model going forward. And CPU releases only get
absolutely critical fixes .. of which the security fixes are the main 
category.

So there won't be a long tail of 9.0.XXX releases like we had JDK 8 
updates / PSUs
which need these backports. Backports will become increasingly rare.

Consider that 8u152 had maybe a year of backlogged fixes.
Some fixes we pushed in May (?) to 8u-dev are only just showing up in 
8u162 b01
for release next year ..
But JDK 10 will be out just 6 months after JDK 9 .. and 9 will then 
become obsolete
and unsupported .. so why does it need non-critical backports anyway ?
People should be on 10 by then.

Backports are going to become rare if I have my facts right.




>
> The criticality of the bug may be perceived differently then,
> depending on who is reviewing the fix. I would personally reserve the
> "critical" term for actual really critical issues (a security
> emergency fix for example, or, indeed, a P1 bug), but have another
> flag to signal the backport request, unless the point of this exercise
> is really to not have upstream backport requests any more other than,
> well, critical ones [1].
>
> There's another concern about this point. A bug is generally
> discovered on a lower jdk version, usually the one in production. For
> instance, this issue was discovered in 8. If only critical issues are
> to be backported, it means that an issue in 8 needs to go in 10
> currently, but can't be ported to 8 and 7 if the updates in between
> don't mark the issue as critical at any given point.

It is something I am still getting my head around that we may have a fix
in 8 and 10 but not 9 .. when we've always previously had the rule that
a fix in release N must also be in N+M for all values of M.

And an LTS like JDK 11 might acquire a fix that isn't in 12, 13, 14, 15 
.. if it
is found and fixed in the 16 time frame.

-phil.
>
> Maybe I'm just giving too much importance on the term "critical" here, though.
>
> Cheers,
> Mario
>
> [1] In which case, rule #1 should really be "do not talk about backports" ;)
>
>
> On Mon, Nov 6, 2017 at 3:51 PM, Rob McKenna <rob.mckenna at oracle.com> wrote:
>> The JDK Updates Project page has been updated with new, draft rules with
>> the intention of streamlining project management:
>>
>> http://openjdk.java.net/projects/jdk-updates/
>>
>> I'd like to leave the draft rules open for discussion for a week, so
>> please let me know if you have any comments.
>>
>>      -Rob
>>