Preparation of update releases

Tue Oct 23 17:41:40 UTC 2018

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

What do you mean here? Prior to RDP2 of 11.0.1 all changes to
jdk/jdk11 and jdk-updates/jdk11u will end up in jdk-11.0.1 and later?
When exactly was RDP2 of 11.0.1?

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

I get more and more comfortable with it :)

The problem is that I still see a lot of changes in 11.0.1 (e.g. for
"8204667: Resources not freed on exception") which have not been
communicated on the vuln-dev mailing list. At the same time, I can't
look at their JBS issues. So I wonder if they are considered "security
fixes" but not communicated on vuln-dev (which would be bad) or if
their JBS issues are just not visible. But in the latter case (i.e. if
they are not security fixes) shouldn't they appear on Kevin's query?
"8204667" for example isn't visible there.

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