[7u communication] Changes to JDK 7u10 plans

[Henri Gomez]

Why not create a specific branch corresponding to Java 7u10 with same OSS contents when Java 7u10 will be release ?

So all packagers could produce their OpenJDK based Java on a known code base. 

Le 9 oct. 2012 à 16:30, Andrew Hughes <gnu.andrew at redhat.com> a écrit :

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