[7u communication] Plans for delivery of critical 7u fixes into CPU releases

[Andrew]

----- Original Message -----
> I think I can see Mario's point/confusion.
> 
> The CPU-critical-request keyword is really just about what you'd like to
> see in Oracle's
> next binary product release and isn't needed for OpenJDK since the fix
> is likely already
> sitting in 7u-dev and just has to be pulled into the CPU binary release.
> OpenJDK doesn't
> do binary releases, and anyone who wants to create a binary release
> based on OpenJDK 7
> sources can do so any time they like based off 7u-dev without caring
> about Oracle
> processes or releases.

Yes, this is what I was aiming at, in a round-a-bout way.  Thanks for
giving a clear answer.

It seems very odd to ask people on the OpenJDK list to contribute to
Oracle's proprietary release.  I, for one, have no interest in doing so.
That's why I was trying to work out if there was actually some benefit
to this for OpenJDK users, but there doesn't appear to be any.

> 
> So it comes down to whether external OpenJDK developers care what fixes
> Oracle
> cares to take in its CPU releases besides security issues.
> 
> I think that at this point in time the basis for Oracle's next 7 CPU
> releases is 7u40 + selected fixes,
> not 7u-dev + selected fixes. And prior to 7u40 GA it was something like
> 7u10 + selected fixes ..
> I'm not sure on that as I've lost track of when 7u-dev has been synced
> with the CPU train.
> 
> But I can also see that distros would generally want to align their
> releases to Oracle's binary
> product releases. And that's particularly so when security releases come
> out. I'm not
> sure if they already do (or want to) follow Oracle's basing them off the
> last non-CPU release.
> 
> But if they base it off 7u-dev then they'll be getting some what more
> 'ahead' of Oracle's releases
> in overall bug fixing at the risk of more regressions  until SQE ramps
> up testing for 7u60.

Distros go with IcedTea (at least, all the ones I'm aware of) which does
provide security releases.  We have 2.3.x tracking u6+ and 2.4.x tracking
u40+.  If we want a fix from 7u-dev to be in, we'll backport it to these trees.
We just pulled the u45 tag into 2.4.x and will be releasing a 2.4.3 release
for the latest CPU over the next few days.  We've also backported these
fixes to the 2.3 tree for a 2.3.13 release, which is still needed by some
(notably for our ARM32 JIT).

7u60 will correspond to 2.5.x, which we haven't started looking at yet, other
than to continue tracking 7u in our HEAD branch.  When u60 forks upstream, we'll
fork for 2.5 in the same manner.  Hopefully, this won't be anywhere near as long
as u40 was.

> 
> -phil.
> 
> On 10/17/2013 7:51 AM, Mario Torre wrote:
> > 2013/10/17 Dalibor Topic <dalibor.topic at oracle.com>:
> >> On 10/17/13 4:29 PM, Andrew wrote:
> >>> ----- Original Message -----
> >>>> On 10/15/13 8:50 PM, Andrew Hughes wrote:
> >>>>> What is the benefit to "OpenJDK 7u Authors, Committers and Reviewers"
> >>>>> of
> >>>>> using our valuable time
> >>>>> to do this?
> >>>> "inclusion into a CPU release before 7u60" "for" "critical fixes"
> >>>> "approved
> >>>> by the Oracle JDK 7u CPU Release Team".
> >>>>
> >>> But you've just said there still isn't going to be OpenJDK CPU
> >>> releases...
> >>>
> >> The Oracle JDK 7u CPU Release Team approves (or rejects) fixes for Oracle
> >> JDK 7u
> >> CPU Releases.
> > I'm not sure I understand why this is relevant for OpenJDK at all then.
> >
> >> Applicable changes are bulk integrated into OpenJDK 7u once an Oracle JDK
> >> 7u CPU
> >> has been released, as was the case two days ago for 7u45.
> > If people want to commit a [security related] patch they can already
> > do so in OpenJDK (following the usual standard procedure).
> >
> > So what exactly changed? Just an easier way for people to send patches
> > to Oracle for inclusion into the closed JDK?
> >
> > Cheers,
> > Mario
> 
> 

-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07