Supporting IcedTea7

[Andrew Haley]

On 02/20/2012 01:42 PM, Andrew Hughes wrote:
> ----- 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"?

I don't know, but I hope it'll be available soon.

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

It's crucial, IMO: it's the only way to find out if a release is
compatible.  It's imprtant not to confuse testing with certification.
Only a binary can be certified, but a release can be tested; of course
it has to be built first.

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

It doesn't.

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

Firstly, it's wholly false to say that Zero& Shark have been allowed
to bitrot.  People have been working on them, and trying to solve some
very difficult problems.  It's a calumny against our developers to
suggest that they have been negligent, because it's simply untrue.
The problems are very difficult to solve.

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

True enough.

>> 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 avoiding the possibility that moving to 2.0 might mean that the
rules might be changed without anyone noticing.  Assuming that they
read this!  :-)

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

Patch review is good.  Process for process' sake isn't.  Slavishly
following rules when it doesn't make sense isn't.  For example, it
wouldn't make any sense to hold back a patch to fix a broken build.

> I don't see how the policy is different from that of, say, gcc.

It is a little bit.  For example, each gcc component has maintainers
who are competent to review patches and can commit to their own areas,
and it has global maintainers who can commit to everything.  But gcc
is a larger and more hierarchical organization, so it's not exactly
comparable.

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

Fair enough, with the caveats above.

> 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

I don't think injecting more process at this sage makes any sense at
all.  It makes far more sense to *discuss* this and try to find a
consensus.  I don't feel we're very far away from one, so why try to
call a vote already?

Andrew.