Supporting IcedTea7

Andrew Haley aph at redhat.com
Thu Feb 16 01:49:00 PST 2012


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.

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.

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.

Andrew.



More information about the distro-pkg-dev mailing list