[11u]: 8u222 & 11.0.4 release schedule

[Lindenmaier, Goetz]

Hi,

> >  The hg-updater issue is blocking us, anyways.
> > If we now pull to jdk11u, it will all be tagged as going to 11.0.3.
> Indeed. This seems like a reason to do it in jdk11u-dev.
Please distinguish one-time contraints from general process
setup. 

> What do you mean by "doing fixes"? Work should go on in jdk11u-dev, not
> jdk11.
Who keeps us from pushing to jdk11u?  We could do so.

> Explicitly moving the focus for release x from the development tree to
> the master tree at rampdown is designed to shift development focus to
> the next release, x+1.
Yes.

> If an issue is found in working on x+1, or in testing x, that is a
> showstopper for release x, then that may be flagged as
> jdk8u-critical-request to get it into the upcoming release.
I think the name 'critical' is bad, it is misleading. The second
tag is needed because we have two codelines, and want to
distinguish for which the downport request is made.

> But otherwise, the intent here is for people to start aiming their work
> at the next release at rampdown. Patches being pushed to jdk11u should
> be rare.
I think we should use jdk11u only for rampdown. So  patches pushed to 
jdk11u should be limited and well restricted, but not necessarily rare.
But yes, definitely less than pushed to jdk11u-dev.
 
> > And it raises the question: why is it merged to jdk11u? It's the
> > same anyways!
> > Thus, following your approach, I would propose to skip merging
> > to jdk11u until start of the rampdown.
> Because jdk11u and jdk11u-dev are aimed at different audiences.
If they are interested in a decent stable version, they should only 
get the repo at rampdown.
I think it's rather because people have certain processes set up, 
and jdk11u-dev is new. 
That again is a bad trigger for basic process decisions.

> The master tree (jdk11u) is snapshots for people to test and integrate
> downstream, leading up to the final release.
No. The jdk11u is a repository used for rampdown so that development
can be continued in another repository, here jdk11u-dev.
It is not a convenience for testers, it is to allow parallel work with 
two different intentions: development <--> stabilization.

> The development tree (jdk11u-dev) is for developers to work on the release.
> 
> I don't see how that's any different to your scenario which, I believe,
> also updates both.
Yes it updates both because others want it that way, but I tried to 
assure at least some stabilization before tagging.
 
> I don't expect developers working on jdk8u development to have to care
> much about the master tree, unless they is a critical issue with the
> upcoming release. I don't expect consumers to care about the development
> tree at all; they should consume solely from jdk11.
Yes, the audience pushing to jdk11u should be smaller than that
pushing to jdk11u-dev.

> As I said before, merging to jdk11u earlier is intended to provide for
> earlier testing of a smaller number of changes. It's an attempt to meet
> your call for earlier testing without locking everything down before
> many people have even had time to work on the release.
People should test jdk11u-dev if they want to test more early.
Then they know they are testing an arbitrary development state 
and nothing in consolidation.

> Which is why I suggest starting such builds over the next week or so.
> 
> My plan for 8u is to integrate the build downstream and do our usual
> builds and testing as much as possible for each tag.
By the way, what is your "downstream"? Is it a repo that 
differs from OpenJDK (kind of as our SapMachine)?
Or is it just a repo that feeds your build/test infrastructure?

Best regards,
  Goetz.


> 
> >
> 
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew