[7u communication] Changes to JDK 7u10 plans

[Andrew Hughes]

----- Original Message -----
> On 10/3/12 11:18 PM, Andrew Hughes wrote:
> > So, are you now saying there *may* be some fixes in the proprietary
> > u10 release
> > which are applicable to OpenJDK?
> 
> No. I don't speculate about the content of future non-OpenJDK
> releases, regardless
> whether they are from Oracle, IcedTea, etc. Despite my good looks, I
> can't predict
> the future, so I don't even bother trying.
> 

I'm  not asking you to speculate, but responding to this statement from your earlier e-mail:

"I would expect Oracle's JDK 7u10 release to have release notes, with a list of fixes, so that once it's released you
could pull the corresponding chagesets out of jdk7u-dev"

In the event that there are changesets in both the proprietary u10 and jdk7u-dev, why is there no
7u10 branch of 7u?  The earlier e-mail would appear to complete rule this out.

> Typically downstream Projects based off 7u end up using the source
> code in 7u as the
> basis and, if they are in the mood for it, adding changes of their
> own to it.
> 
> A good example is IcedTea, which in a typical release (see
> http://markmail.org/message/st2d3zjccucgz6tb)
> will include additional fixes that take it "beyond" a particular 7u
> forest it was
> based off. It's impossible for me to predict which fixes, if any,
> those would be
> ahead of time, since the decisions about their inclusion into IcedTea
> are not made
> here, they are made  downstream, in the IcedTea Project. And that's
> fine, too. It
> also is true for any downstream.
> 

Yes, as the maintainer, I'm aware of how IcedTea works.
It's also not so much a case of "being in the mood for it" as OpenJDK
as is still being in an unpackageable state.

We're working towards making OpenJDK itself usable at which point we'd
want to dispense with IcedTea as an interim layer.  This will be impossible
if 7u does not have a sane release system with trees for all releases, including
security updates.

This benefits 7u as well as it means we're working on it with you, rather than just
cleaning up regressions afterwards.

> Which brings us back to your initial question - what the IcedTea
> release corresponding
> to 7u11 could be based on. One option is a future IcedTea release
> corresponding to 7u9.
> Another option is 7u-dev, as you mentioned yourself. Another option
> is to cherry-pick
> fixes from jdk7u-dev that you care about. And so on - I'm sure you
> can come up with more.
> I don't know which option is best for IcedTea. I would, though, if in
> doubt, go for
> whichever seems to be the lowest risk one in the context of IcedTea.
> 
> > Also, why aren't there trees for e.g. u3, u5, etc. (the security
> > CPUs)?
> 
> I'll quote from this Project's Q&A web page:
> 
> "As with OpenJDK 6, security fixes are first kept confidential and
> applied to a private
> forest before being pushed to the public forest as part of the
> general synchronized
> publication of the fix to affected JDK release trains."
> 

That doesn't answer the question which is why said "public forest" has to
be 7u HEAD and can't be a specific branch of 7u.  Pushing the security fixes
to an e.g. 7u9 tree would be little more trouble, especially as I presume Oracle
security updates for u9 aren't based on random snapshots of 7u10 development, but
something more stable.

> > This gives the impression that 7u is not meant for direct use, but
> > only as a basis
> > for something else like IcedTea, if we're going to have releases
> > with no applicable
> > tree, or even tag, and security fixes are applied to a mid-stream
> > feature release.
> 
> That depends on the point of view. We don't publish binaries, so from
> one point of view,
> there is nothing you can use directly - you need to build your own
> binaries, or find a
> downstream that does that for you, like Oracle JDK. From another
> point of view, the
> releases created by this Project are well usable on its own, once
> you've ran make (and I'm
> a happy user). From yet another point of view, that's not something
> you'd want to run as
> a a non-technical user, because it lacks additional features like
> plugin, web start, etc.
> 
> So, in practice, it depends on one's perspective. I would expect most
> users of 7u to run
> a binary published downstream, though.
> 

I'm not talking about users so much as having a source release that distros
can take and build, just like about every other FOSS project.

> > I'd really like to see a situation where, for all releases, there
> > is a specific point
> > on a specific tree that can be used to download the source for that
> > release, as in most
> > other FOSS projects.
> 
> We already provide that for releases developed in this Project. See
> http://jdk7.java.net/source.html
> for the links for 7u6, which was the last release developed in this
> Project.
> 

This only lists u6.  There is nothing at all for e.g. u5.

> cheers,
> dalibor topic
> --
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
> Oracle Java Platform Group
> 
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Geschäftsführer: Jürgen Kunz
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> 
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed
> to developing practices and products that help protect the
> environment
> 

-- 
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