Preparation of update releases (original) (raw)

Rob McKenna rob.mckenna at oracle.com
Tue Oct 23 16:23:45 UTC 2018

On 23/10/18 17:45, Volker Simonis wrote:

On Fri, Oct 19, 2018 at 6:19 PM Rob McKenna <rob.mckenna at oracle.com> wrote: > > 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. >

Yes, but this doesn't solve the problem of duplicate changes and the inability of the community to follow which non-security changes will be in the next security update if such a changes get manually "cherry-picked" from the open updates repo into the closed security updates repository.

Prior to RDP2 all open contributions will end up in the corresponding update release.

Kevin gave a jql query below which should help though, is that insufficient?

-Rob

That's why I was suggesting the creation of an "open" clone for every security update repository in order to transparently collect the non-security changes there. This still doesn't solve the issue with "duplicate" changes after merging the security-repo back into the main updates repo, but it makes it clear for everybody which non-security changes will be in an security update. > -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