[8u-communication] JDK 8u202 RDP2

[dalibor topic]

On 21.11.2018 17:38, Severin Gehwolf wrote:
> Perhaps it's because it's been the only one which happens to have been
> pushed after u202 has been forked Oracle internally? After that I
> haven't seen many approvals for jdk8u, perhaps because current
> maintainers are reluctant to approve something they won't maintain any
> more when the release happens? It's a bit of a mystery to me.

Story time.

A couple of years ago when I was the Project Lead for JDK 7 Updates 
preparing the Project to be transitioned to a new Project Lead, I was 
faced with an interesting logistical problem.

On one hand, the transition to a new Lead and new maintainers taking 
care of approving changes would take place after the last release under 
my responsibility, but on the other hand, technically, while that last 
release was in rampdown, the development forest was still open for the 
next release for everyone to push their changes in ( pending maintainer 
approval) - a release that neither I nor the maintainer team would 
actually be responsible for.

Consequently, two problems would arise, if we had continued to approve 
fixes before the actual transition took place:

a) I'd have to hand over the Project in a 'messy' state, with the next 
release already well in progress with potentially dozens of changes the 
next Project Lead had no say in and would have to take in or back out 
again. Each such change carries a maintenance cost and a maintenance risk.

That's not just a theoretical concern - a few weeks ago on this list a 
backport of AppCDS was proposed. That's precisely the kind of far 
reaching change that I believe must be discussed, understood and 
approved by the Lead and maintainers that would carry its maintenance 
cost and risks, rather than by the outgoing ones.

That is why my suggestion was to restart that discussion after the 
transition in this Project.

b) I'd be asking my fellow Maintainers to work on approving changes that 
they were not actually responsible for delivering, effectively asking 
them to set aside other things they were actually responsible for 
delivering, and risking that they'd find themselves in the middle of 
threads questioning their approval decisions down the road by the next 
set of maintainers actually responsible for delivering on them. [0]

In short, for my fellow Maintainers continuing to be responsible to 
approve changes to JDK 7 Updates that they weren't responsible for 
actually maintaining had all kinds of potential downsides, but no upside.

So, as the JDK 7 Updates Project Lead I chose the simplest path forward, 
carrying the least risk of messing up the transition: I would leave all 
changes that would be proposed after rampdown to the wisdom of the next 
set of maintainers. In short, we had a clean cut from one set of 
maintainers to the next.

That worked, of course, but it wasn't always great for everyone either, 
as I believe some people had to sit on their changes until the 
transition took place.

With the upcoming transition in this Project, Sean, i.e. the Project 
Lead, has chosen [1] a different and I think better path - to widen the 
set of Maintainers ahead of the transition, making the approval process 
a bit smoother in consequence, so that potential future maintainers 
would be able to approve changes for their next release before the 
actual transition of Project Leads.

TLDR: I assume that approvals will pick up again once the new 
maintainers are on board.

cheers,
dalibor topic

[0] I'll leave a story involving two letters here for future 
maintainers: 
https://www.washingtonpost.com/archive/politics/1982/01/15/a-tale-of-two-letters/e1f65aa4-66ce-4991-8a1b-840fc6956766/?noredirect=on&utm_term=.26ad7b2224af 
;)

[1] 
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-November/008179.html
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment