Preparation of update releases (original) (raw)
Rob McKenna rob.mckenna at oracle.com
Fri Oct 19 16🔞47 UTC 2018
- Previous message: Preparation of update releases
- Next message: Preparation of update releases
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 >
- Previous message: Preparation of update releases
- Next message: Preparation of update releases
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]