JDK Updates Project Page

[Mario Torre]

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

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
>