8u/11u repo access and Jira changes

[Lindenmaier, Goetz]

Hi Andrew,

> It depends a lot on the vulnerability group, but yes, I was thinking
> the start of the month of the CPU (so April for this next one).
That seems to be a good point, I don't think we should go
more later, rather more early.
If it wasn't for jcheck not accepting other tags, I would propose 
to tag it at that point with 11.0.3-rc (For release candidate, see JEP 3).

Best regards,
  Goetz.




> -----Original Message-----
> From: Andrew Hughes <gnu.andrew at redhat.com>
> Sent: Monday, March 4, 2019 6:09 PM
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net;
> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Aleksey Shipilev
> <shade at redhat.com>
> Subject: Re: 8u/11u repo access and Jira changes
> 
> On Mon, 4 Mar 2019 at 06:42, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> >
> > Hi Andrew,
> >
> > > > 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?
> >
> > It has, yes.
> 
> Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-)
> 
> >
> > > 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.
> >
> > Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA).
> We only expect few stabilization changes. And whenever you start your work
> on the security repo, you can do merges from jdk11u back into your private
> repository at any time.
> >
> > Having said that, I, however, agree, that 'ga' should not be a merge
> between something that you worked on an tested in private and something
> that has diverged meanwhile in the public.
> > That means, between the point when you've synced the last public
> jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) ==
> jdk11.0.3-ga, there must not be changes in the public repository.
> > So we should announce on the mailing list when we have a tag that we
> intend to use base for GA. And after that, no pushes any more to jdk11u,
> that's your hard freeze. :)
> > What'll be the time you need for that final round of testing? Maybe 1-2
> weeks before GA?
> 
> Yeah, I'd prefer to keep such merges to a minimum and only really
> essential fixes should be going in during the later stages.
> i see four changes already post-tag.
> 
> It depends a lot on the vulnerability group, but yes, I was thinking
> the start of the month of the CPU (so April for this next one).
> 
> >
> > Best regards
> > Christoph
> >
> 
> 
> --
> 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