Preparation of update releases

[Kevin Rushforth]

I'm sure Rob will respond to the rest of this, but here is a correct 
filter to find all bugs that are newly fixed in 11.0.1:

https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%2011.0.1%20AND%20(labels%20is%20EMPTY%20OR%20labels%20not%20in%20(hgupdate-sync))

There are a only 8 new public fixes that went into 11.0.1. The 
"hgupdate-sync" label indicates a fix synced in from an earlier release 
in the same release family, so excluding those will give you an accurate 
picture.

-- Kevin


On 10/19/2018 7:07 AM, Volker Simonis wrote:
> Hi,
>
> after 11.0.1 has been successfully released I'd like to describe some
> of my observations on how this release has been prepared and suggest
> some improvements to the process:
>
> - I first, naively expected that 11.0.1 will only contain security
> fixes (i.e. the fixes circulated and discussed on the vuln-dev mailing
> list)
> - in the end I was a little surprised that in addition to the ~20
> security fixes 11.0.1 also contained ~130 other changes
> - so in the end 11.0.1 is not strictly speaking a "security release"
> but more a kind of combined "security" and "maintenance" release.
> - because 11.0.1 was prepared in a hidden clone inside Oracle, it is
> hard for others to understand which of the changes in jdk11u will also
> be integrated into 11.0.1. (I know I can list all the issues fixed in
> 11.0.1 in JBS, but this gives me more than 1000 changes which is not
> near the additional ~130 changes which are in 11.0.1 compared to 11).
> - in the end, this makes it hard for anybody outside Oracle to prepare
> and test a security update like 11.0.1, which will be close to what
> will be finally released in the OpenJDK updates project, even if he
> has access to the required security changes (because he simply can not
> know which other changes Oracle integrates into the corresponding
> security update).
>
> I would therefore like to propose the following procedure for the
> creation of future security updates:
>
> - for every security update, create a corresponding "xxx-open" clone
> in the OpenJDK updates project. E.g. for 11.0.1 we could have created
> "jdk-updates/jdk11u-11.0.1-open"
> - the hidden repository required for the collection of security
> changes should be cloned from the corresponding "-open" repo
> - the hidden repository should only be used for pushing security fixes
> - all other fixes intended for that respective security release should
> be downported from the corresponding general updates repository (e.g.
> jdk11u) where they have to be downported first, into the corresponding
> "-open" repository (e.g. jdk11u-11-0.1-open).
> - the hidden repository should regularly merge in the changes from the
> corresponding "-open" repository.
>
> The benefits of this approach would be:
>   - it is transparent for everybody what non-security changes will be
> in the next release
>   - for parties having access to the security fixes it would be trivial
> to prepare and test an update release behind closed walls which will
> exactly correspond to what the final OpenJDK update will be.
>
> The only downside I can see so far is:
>   - the extra effort of creating the new "-open" clone in the updates
> project (but notice that such a clone will in general only live for
> about three month after which he can be switched to read-only mode or
> even deleted after the corresponding hidden repository was merged in
> the general updates repo.)
>
> What do you think? I'm of course especially interested in the opinions
> of Oracle and potential future Update Project maintainers.
>
> Thank you and best regards,
> Volker