Preparation of update releases

[Rob McKenna]

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
> > > >
> > >