----- Original Message ----- > 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. >
That's exactly what I'm asking. Either u10 only has changes to the proprietary JDK code, or it contains OpenJDK changes but for some reason they are not be put in a separate branch. It isn't clear to me which of these is true. > Le 9 oct. 2012 à 16:30, Andrew Hughes <gnu.and...@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 > > > -- 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
