8u/11u repo access and Jira changes

[Andrew Hughes]

On Tue, 26 Feb 2019 at 21:41, Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Andrew,
>
> > The questions I really need answers to are:
> >
> > 1. Who is going to push from jdk8u-dev -> jdk8u?
>
> The maintainers (you, Aleksey, me, Goetz, ...)
>
> > 2. What is the frequency of these pushes going to be?
>
> Ok, again, here's our proposal (from the SAP folks):
>
> We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to jdk8u once all open Oracle backports were integrated.
> Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly (by those who set the tags, that is, the maintainers).
> At the release day, you'll sync your security work on top of jdk8u/jdk11u and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to the same change). And this will be integrated back to jdk11u-dev.
>
> What do you think of that?

I can live with that. I'm a bit nervous about pushing changes to jdk8u
before jdk8u-dev, but as long as it is tested regularly and integrated
back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet?

On your final point, the -ga tag will be the point at which we branch
+ the private CPU changes (which will be smaller than the batches
Oracle pushed, as we are only keeping private those that are
embargoed, not the entire release set). This is why I suggest we
declare the branch frozen at the point we use as a base internally, so
there are not changes between the baseline for the CPU and when we
push upstream. Tagging -ga after a merge would represent something
different from what we have already based our update binaries on.

The tagging is no different from the way things worked under Oracle;
they also tagged what their binaries were built from, not the point it
was merged. Where I hope we can be more open is in making it clear
what our base looks like for these CPU patches, and those within the
vulnerability group should be able to replicate the same thing for
their own pre-embargo binaries.

>
> > 3. What testing is going to be performed prior to these pushes?
>
> Good question, currently I guess it's our quality testing at SAP plus whatever you have at RedHat. We should eventually get to something better, e.g. have some open test results from AdoptOpenJDK...??

Ok, I guess once we have the changes tagged in a repository, people
can do their testing and report issues.

>
> > I'd prefer regular pushes with tags, because that would help us
> > downstream (aarch64-port/jdk8u-shenandoah,
> > shenandoah/jdk11) in being able to integrate changes more frequently.
> > Under Oracle, we've had to do that at GA time only.
>
> That should be helped with our concept.

Sounds good.

>
> Best regards
> Christoph
>

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222