Request for approval: Backport of 6781583 to hs14/OpenJDK6 (original) (raw)

Andrew John Hughes gnu_andrew at member.fsf.org
Wed Jun 10 08:37:25 PDT 2009

2009/6/9 Paul Hohensee <Paul.Hohensee at sun.com>:

Yes, we want you to create a fork.  We can work together on the fork.

The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it is our 6u14 hotspot repo.  As such, we need it to stay as is so we can use it as the basis for customer one-offs containing single fixes, etc.  Think of hs14 as a distro repo that happens to be public.  Would it make sense for a company like Redhat to have allowed community changes to, say, it's ES 5.1 repo after it shipped?

I'm sorry, but I can't follow your logic here. From what you've said in previous emails and simple common sense, I can't see these customer one-offs being created one on top of each other in the public repository. So what you seem to be saying is you need to keep the tip of the repository the same as it is now for these private forks - why not just tag the tree at this point and use that tag for future private forks for customer one-offs? Things would be much easier generally if the HotSpot 'releases' (hs16b03, etc.) were tagged, as I believe has been mentioned before.

What we believed was asked for was a stable repo that could be used as the basis for things like 6-open.  As I said, feel free to clone hs14 for that purpose and then update the clone.  Doing so seems to us to fulfill IcedTea developer requirements.

To be honest, it doesn't really matter that much whether we use hsx or a clone to me; I'm just trying to understand why effort was put into creating a forest which is essentially frozen in time.

What worries me is that this discussion keeps throwing up 'us' and 'them' scenarios, as you refer to here with 'IcedTea developer requirements'. I thought we were trying to work together as an OpenJDK community which includes those inside Sun and those outside it (which is represented by our newly expanded IGB). As far as IcedTea requirements are concerned, the mere availability of an updated hs14 has allowed us to ship IcedTea6 1.5 with this included. The push for updating OpenJDK6 and making it actually buildable on a modern system is because we want OpenJDK itself to succeed for the benefit of everyone.

That's the last thing I'm going to add with regard to this, as the whole conversation seems to have gone on too long and doesn't appear to be getting us anywhere. Please just let us know when there is a hs14 available somewhere to which we can contribute our patches.

SSRs are Synchronized Security Releases put out by Sun to fix particular security holes across all Sun-supported jdk releases at the same time.  They contain only security fixes, so non-security fixes like this one are off-limits. What we call Limited Update Releases can contain other-than-security fixes. We alternate jdk6 update releases between SSRs and LURs. > Paul > Andrew John Hughes wrote: >>> 2009/6/9 Paul Hohensee <Paul.Hohensee at sun.com>: >>>>>>> There seems to be some confusion here. >>>>>>>>> Clearly, because what I believe we asked for was a stability branch > and that was the point of going through this whole process for over > three months.  Why setup a forest unless it will be updated? >>>>>>>>> hs14 is the version of hotspot that shipped with 6u14 and as such, is >> frozen. >> We do not intend to apply or allow any further bug fixes to it, including >> the >> one you propose here. >>>>>> I'm not asking you to apply it.  I'm suggesting that I do. >>> It was never intended to be the basis for another >>>>>>> openjdk >> version of hotspot. >>>>>> The entire point of making hs14 available was to use it in > OpenJDK6, at least from the point of view of IcedTea developers. >>> Ongoing hotspot development goes forward only in the >>>>>>> openjdk hotspot repo, which is currently labeled hs16.  Of course, anyone >> may >> feel free to clone hs14 if they like, and apply what fixes they will to >> said >> clone. >>>>>> So you want us to create a fork?  How does that help us all work together? >>>>>>>>> One of those clones could easily be jdk6 open, but that's not our (the >> hotspot >> group's) decision to make. >>>>> The next jdk6 update release will include a new version of hotspot, based >> either on hs14 (in which case it'll be an SSR, we'll likely call it >> hs14.1, >> and this >> fix will be off limits) >>>>>> Why? >>> or the current openjdk hotspot repo (in which case >>>>>>> it >> will be a limited update, it'll likely be hs16, and the fix is already in >> it).  The >> going-forward release is hs16.  hs14 is a dead end. >>>>> Paul >>>>> Andrew John Hughes wrote: >>>>>>>>>> 2009/6/8 Andrew John Hughes <gnuandrew at member.fsf.org>: >>>>>>>>>>>>>>>>> The following webrev: >>>>>>>>> http://fuseyism.com/6781583/webrev.00/ >>>>>>>>> is backported from OpenJDK7.  It allows hs14 to be built using GCC 4.3 >>>> and above.  Otherwise, the build fails.  IcedTea has been applying an >>>> equivalent fix as three separately developed patches, two of which >>>> have been there pretty much since its inception in the summer of 2007. >>>>>>>>> Ok to commit? >>>> -- >>>> Andrew :-) >>>>>>>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8 >>>>>>>>>>>>>>>>>>>>>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>>>>>>>>>>>>>>> Thanks,

Andrew :-)

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

Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

More information about the jdk6-dev mailing list