Supporting IcedTea7

[Andrew Hughes]

----- Original Message -----
> On 02/15/2012 10:01 AM, Andrew Hughes wrote:
> 
> > Our support for IcedTea7 seems to be lacking, despite it becoming
> > the primary release (and the only one on Fedora 17 on).  During
> > this
> > release cycle, I've noticed several cases of patches being in
> > IcedTea6 but not in IcedTea7, and developers on IRC have been
> > hitting basic build issues, despite the release having occurred
> > about four months ago.
> >
> > I'd like to suggest that we switch to a similar policy to OpenJDK
> > (Dalibor calls it the 'no fix left behind' policy) where fixes for
> > IcedTea6 have to go into IcedTea7 first.  I think this will make it
> > less likely that things will get missed and should concentrate
> > people's minds on the new 7 series rather than 6.
> >
> > To begin with, the ARM port will have to be an exception but I'd
> > also like to see this switch primarily to 7, once it works there.
> >
> > Thoughts?
> 
> A few things.
> 
> Firstly, the free world still doesn't have the JCK, so we can have no
> idea if OpenJDK 7 is Java compatible, although it probably is.  It
> can never be a primary release for many users until OpenJDK users and
> packagers have some way of doing compatibility testing.
> 

http://openjdk.java.net/legal/ lists both licenses now, so how does
"the free world" not "have the JCK"?

Besides, this discussion is about *source* releases, while the JCK
only applies to binaries.  We've never made it a requirement that
IcedTea source releases have a JCK-passing binary and some distros
have never even run the 6 JCK, so I don't see how it's relevant to
where we focus the majority of IcedTea development.

With regard to the Fedora release, this is not a decision that's anything
to do with me and I believe it's already one that's been made.  The last I
heard, F17 would be 7 only.

> Secondly, while this policy makes sense in the abstract, it does not
> make sense to apply it rigidly.  Zero still doesn't fully work in
> OpenJDK 7, so it makes no sense for it to be the primary platform for
> Zero development.
> 

This is exactly why more work needs to be going on in the 7 tree, not less.
How does concentrating on 6 help this at all?

One of the main reasons I raised this issue is because we've just shipped
a new 7 release that has seen little work from anyone other than myself,
and with Zero and Shark builds broken.  This doesn't look good.  Unlike the
ARM port, Zero & Shark DID work and have been allowed to bitrot, as Oracle
have continued development on HotSpot and we haven't.

It doesn't make sense for development to keep focusing on the dead end that
is OpenJDK6.  Even 7 is only a halfway house; to properly work within the
OpenJDK community, development should be on 8 first, then backported to 7 & 6.
This is where Oracle are working and it doesn't make sense for us to focus
all our efforts on a release that should really just be seeing security
fixes and backports now.

> Lastly, the "CommitPolicy" page attempts to impose more rigid
> policies
> for IcedTea7 HEAD / forest post 2.0.  While proper patch review is
> undoubtedly a good thing, there are cases where it is inappropriate.
> In some areas, for example, the committer is the only person who
> really understands the code.  In other cases it's obvious what needs
> to be done, and the process serves no purpose.  I suspect that this
> is one reason why our support for IcedTea7 may be lacking.
> 
> So, while this policy makes some sense, let's use it as a guide
> rather
> than a straitjacket.
> 

If this is an issue, we can discuss it as a group and change things.  I wasn't
aware it was until you raised it here.  Although the page says that about 2.0 on,
it's generally not been enforced so far.

I'm a little confused as to your position on this.  You've seemed to say
in previous e-mails that patches should be reviewed on entry to HEAD (which is
what this 2.0 change would bring about) rather than on going into review branches.
You seem to be saying the opposite here.  Which is it?

I don't see how the policy is different from that of, say, gcc.  We allow trivial
fixes through and, in fact, are less restrictive in allowing unreviewed commits
to HEAD.  We can certainly have exceptions for areas like ARM and Zero *code* but
I do think all changes to the build (OpenJDK & IcedTea) should be reviewed.

Our release branches require review and this has generally not stopped people committing
to them.  So I don't see immediately why this would be the issue with 7.  From my
observation of discussion on IRC, it seems most people haven't even tried BUILDING
it, never mind getting to the point of committing patches.

I'll write a formal proposal and we'll vote on this policy switch using the same simple
majority policy as OpenJDK: http://openjdk.java.net/bylaws#_3

> Andrew.
> 

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