Request for approval: Backport of 6781583 to hs14/OpenJDK6

[Paul Hohensee]

Excellent idea. :)

Paul

Martin Buchholz wrote:
> Paul,
> Thanks for the clear explanation.
>
> Given this, I'm thinking we lobby Joe Darcy
> to use a *copy* of hotspot 14 stable
> as the hotspot to use with OpenJDK6.
> Which can then evolve with community input.
> Andrew can do the first commit.
>
> Martin
>
> On Tue, Jun 9, 2009 at 04:00, Paul Hohensee <Paul.Hohensee at sun.com 
> <mailto:Paul.Hohensee at sun.com>> wrote:
>
>     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
>         <mailto: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
>                 <mailto: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.
>
>                      
>
>
>
>
>          
>
>