JDK Updates Project Page (original) (raw)

Mario Torre neugens at redhat.com
Thu Nov 9 11:50:11 UTC 2017

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. 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 -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.

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.

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

More information about the jdk-updates-dev mailing list