8u/11u repo access and Jira changes

[Lindenmaier, Goetz]

 Hi Andrew, Aleksey, community,

Before, I proposed this, but got no comments:
> I (backed up by Christoph and the rest of the SAP team)  would volunteer to
>  1. tag jdk11u on a weekly basis after running our tests (if there was a change) 
> 2. merge the tag to jdk11u-dev and run tests on the merged repo
> 3. push the changes to jdk11u-dev the day after.

Should SAP take the role of doing above merges?

Best regards,
  Goetz



> 
> I would propose to tag the change that is built by our infrastructure on
> 
> the night Tuesday-Wednesday,  which is usually pulled on Tuesday 18:00 CET.
> 
> In the night Wednesday-Thursday, the tests would run on jdk11u-dev
> including
> 
> the changes merged from jdk11u.  Test results will pop up during the day
> (Thursday),
> 
> the merged changes could be pushed on Thursday evening or Friday morning.
> 
> 
> 
> Our testing currently covers the following:
> 
> 
> 
> We build the following platforms:
> 
>   Aix
> 
>  Linux ppc64
> 
>  Linux ppc64le
> 
>  Linux s390x
> 
>  Linux x86_64
> 
>   mac
> 
>  Solaris sparc
> 
>   Windows x86_64
> 
>   Windows x86_32
> 
> We finally got an aarch64 machine, we could add that to the tests.
> 
> 
> 
> We run the following tests every night:
> 
>   A big part of the jck tests (excluding those requiring  manual testing, and a
> list of shaky tests)
> 
>   The jck tests with -Xcomp and C1, and with -Xcomp and C2.
> 
>   The hotspot and jdk jtreg tests, excluding those marked with key "headful",
> "printer" and "intermittent"
> 
>   Jvm2008, jbb2015, jvm98
> 
>   And finally some SAP applications.
> 
> 
> 
> But I'm also fine with leaving this task to RedHat, Aleksey or Andrew Hughes
> or whoever
> 
> would be available on your side.
> 
> 
> 
> For the move jdk11u-dev-->jdk11u, which happens only once a release, we
> should
> 
> do this by communication on the mailing list.
> 
> 
> 
> Best regards,
> 
>   Goetz.
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> 
> > From: Langer, Christoph
> 
> > Sent: Tuesday, February 26, 2019 10:41 PM
> 
> > To: Andrew Hughes <gnu.andrew at redhat.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
> 
> >
> 
> > 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?
> 
> >
> 
> > > 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...??
> 
> >
> 
> > > 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.
> 
> >
> 
> > Best regards
> 
> > Christoph
>