Preparation of update releases (original) (raw)
Volker Simonis volker.simonis at gmail.com
Fri Oct 19 14:07:18 UTC 2018
- Previous message: [11u] Request for Approval: Backport of 8209576: java.nio.file.Files.writeString writes garbled UTF-16 instead of UTF-8
- Next message: Preparation of update releases
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: [11u] Request for Approval: Backport of 8209576: java.nio.file.Files.writeString writes garbled UTF-16 instead of UTF-8
- Next message: Preparation of update releases
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]