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