Preparation of update releases

Rob McKenna rob.mckenna at oracle.com
Fri Oct 19 16:18:47 UTC 2018


7 too many!

So, with the new bar for approvals in the jdk-updates project, this
should become less of an issue. Which is to say, a bug that can be
pushed via the open repo should be.

    -Rob

On 19/10/18 07:43, Kevin Rushforth wrote:
> Correction, there are 7 new public fixes in 11.0.1.
> 
> -- Kevin
> 
> 
> On 10/19/2018 7:35 AM, Kevin Rushforth wrote:
> > 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
> > 
> 


More information about the jdk-updates-dev mailing list