OpenJDK 8u272 Released

[Langer, Christoph]

Hi,

> On 10/21/20 6:00 PM, Andrew Hughes wrote:
> >>  From my point of view, the ideal workflow would be to push the changes
> >> to the OpenJDK update repos right after the embargo was lifted. After
> >> that anybody can use these repos as "golden master" and create source
> >> bundles, binararies, etc from them. Or am I missing something?
> >
> > That might be better, but it would be a change for how we have done
> > things for the last decade. As I say, the repos, source bundles and
> > binary bundles all have different target audiences. I don't think it's
> > correct to assume everyone who wants the new release is able to build
> > their own from a repository.
> 
> I am reluctantly against pushing anything to the public repos without a
> second (hopefully
> non-involved) person looking at it. The rare exceptions are clean merges
> from other public repos.
> Human errors happen, and reviews help to catch them early before they
> propagate. IMO, 8u and 11u
> work is too important to take process shortcuts.

I think, for the CPU patches, the review ought to be done in the VG, prior to the release date. Then, when the embargo is lifted, the changes should be merged into the public repos. That's also what Oracle does for the short term releases (e.g. 15u). There is no public review, they're just merging their closed source tree with all build tags into the public repo.

Of course, when the CPU updates are visible publicly, it's everybody's call asked to have a look at the changes and immediately report any critical problems. But as Andrew said, the compiled set of patches can't be modified at the time of the "Review" anyway. Further feedback will have to be incorporated as a patch on top. And if we then see a real critical issue, we always have the option to add another build tag after the release and maybe even move the ga tag.

> 
> Even if formally CPU RFR can only result in prompt fixes on top of already
> released builds, still,
> this would be the second line of defense against proliferating obvious CPU
> regressions (the first
> line being VG itself). That is, if anyone would detect a source code problem
> with a public CPU
> patch, that is better to be discovered the moment embargo lifts. This is
> coincidentally when CPU RFR
> happens.

Sure, I agree, but not as an RFR process, holding up the merge of the CPU changes.

> > Note that you may not have noticed this with previous releases because
> > Aleksey has been doing an excellent job of reviewing them almost
> > immediately.  I'm sure he'd appreciate the extra sleep if he's no
> > longer on the hook to do that late on unembargo days.
> 
> Thanks, yes, that would make my life easier :)
> 
> But this actually gives us a middle ground here: if we want the patches to be
> pushed promptly and
> with review, then consider being on-call around the embargo datetime, so
> you can review/clear
> Andrew's RFR promptly (hopefully before Andrew himself calls it a day). As
> Andrew mentions, I did
> that for previous releases, so maybe other folks would consider to stay
> around for next releases
> too. That's how it is supposed to work, methinks: if you want something to
> happen (quickly) with a
> due process, then show up and give a helping hand.

Totally in agreement.

Cheers
Christoph