Preparation of update releases

[Kevin Rushforth]

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
>