8u Approvals and Rampdown

Andrew John Hughes gnu.andrew at redhat.com
Thu Nov 28 05:43:46 UTC 2019


Hi all,

You will have noticed that we have developed a backlog of approvals
recently and this is in part due to some apparent confusion over the
approval process.

Approval should be requested once the patch is ready to be committed to
the appropriate 8u repository (8u-dev for jdk8u-fix-request, 8u for
jdk8u-critical-request).

With 8u, patches often need substantial backport work before they reach
this point. To keep things moving at a good pace for everyone, it is
important not to use up the relatively low bandwidth we have for
approvals with queries and reviews that would be better targeted at the
mailing list as a whole.

So:

* If you want to know if something is worth backporting, start a
discussion on the mailing list. Feel free to add your own label to the
bug for reference, but don't flag for approval at this early point.

* If you find a bug you believe is 8u only, then please file a bug and
discuss it on the mailing list, but don't flag the bug for approval
until you have a reviewed patch for it.

* If backporting a patch requires anything more than path changes (which
should be able to be automated using the scripts in the repositories),
then post a request for review to the mailing list. Once a 8u reviewer
is ok with it, then proceed to flagging for approval.

This should mean that everything in the 8u approval queue is then either:

a) A clean backport (sans path changes)

or:

b) A reviewed backport with corresponding mailing list thread

This will make life easier for both maintainers and those waiting on
approvals.

At present, we are seeing a mix of bugs in all states in the approval
queue, which ends up turning what should be a rubber-stamping process
into one where the maintainer ends up also doing a lengthy review or
even trying to determine the validity of a new patch from scratch. This
makes each approval take longer, meaning everyone has to wait longer to
get their patch approved. In many cases, the issue will end up staying
in the queue because further feedback is needed from the author.

Such issues are to be expected in the early days of maintaining 8u, but
as we all get used to the process, things should get better. If you
think things like this can be clarified better in the documentation,
please let us know.

I have just finished reviewing the list of 8u242 bugs to see our current
status as we begin rampdown. I'll post at length on this tomorrow when
I've reviewed a final few patches,  but please be prepared for the
switch to 8u252 development and the need to consider whether your bug
still needs to make 8u242 or not.

Thanks,
-- 
Andrew :)

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

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



More information about the jdk8u-dev mailing list