Request for approval: Backport of 6781583 to hs14/OpenJDK6

[Paul Hohensee]

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?

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.

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