Preparation of update releases

[Volker Simonis]

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