icedtea7 releases (was Re: RFC: backport S7104625 to icedtea7 forest)

[Dr Andrew John Hughes]

On 17:10 Tue 13 Dec     , Omair Majid wrote:
> On 12/12/2011 06:11 PM, Dr Andrew John Hughes wrote:
> >> If you need this fix earlier, I can add this to icedtea7 as well. Though
> >> I would rather avoid the extra work and just wait until the next sync :)
> >>
> >
> > I think this is something we need to discuss.  I've not had much luck finding
> > out the schedule for these updates from Oracle.  From
> >
> > http://openjdk.java.net/projects/jdk7/builds/
> >
> > it seems that u2 is supposed to be released tomorrow, but I see little discussion
> > about this on the jdk7u mailing list.  There are no dates on that calendar for
> > future releases.
> >
> > We should look at pulling u2 into IcedTea7 and doing a 2.1 release.  I'll post a
> > list of changesets to see what this equates to.
> >
> > We also need to discuss how we are going to handle such updates generally.
> > As we don't even know when u4 is going to appear, it may be judicious to backport
> > this particular changeset ourselves to IcedTea7.
> >
> 
> I would like to add my thoughts to this discussion.
> 
> First, I think it would be beneficial to keep version numbers as close 
> to openjdk/proprietary jdk as possible. It was quite strange in the 
> openjdk6 time-frame where the openjdk (6bXX) releases were not related 
> to proprietary jdk6 (6uYY) at all. I recall a number of users saying 
> that because YY was greater than XX, openjdk was lagging behind the 
> proprietary jdk.

Well yes, that's true and Oracle acknowledge it too.  But this
couldn't be helped; due to the genealogy of OpenJDK6 the two are
completely unrelated and incomparable, coming from completely
different code repositories.  Thankfully, this period is mostly behind
us now.

 I imagine it will be hard for users to figure out that 
> icedtea2.1 is approximately openjdk7u2, and not openjdk7u1. Perhaps we 
> can even utilize this to our advantage and keep odd minor numbers (2.1, 
> 2.3, 2.5 and so on) reserved for our own releases which may contain 
> important non-openjdk stuff (I am thinking of things like ports, 
> architecture support, a number of important bug fixes. and so on).
> 

I think that would be difficult to make work because it puts hard constraints
on what we can do; it would be more confusing if we skip version numbers
because there are e.g. no ARM support changes to make a 2.3 release, so
we end up going 2.0, 2.2, 2.4, 2.5 or something.

We also have a tradition of following the more usual FOSS pattern of applying
security updates to supported releases rather than doing a whole new release
for a security update as Oracle does for Java and Mozilla do for Firefox.
I believe distros find this better, but speak up if this isn't the case.

I don't think the end users see the IcedTea version that much anyway
(especially based on how bugs are reported).  The confusion was
between b22 of OpenJDK6 not being the same as b22 of the proprietary
JDK.  I envisage 7u2's version output being something like:

java version "1.7.0_02"
OpenJDK Runtime Environment (IcedTea7 2.1) (Gentoo build 1.7.0_02-b21)

which I believe is close to the proprietary VM (it would be good if someone
could include the output of that for comparison).  The IcedTea version
is clearly separate.

This is based on:

http://hg.openjdk.java.net/jdk7u/jdk7u2/rev/50b5ada8ca3e

the latest commit to the jdk7u2 repo.

> Second, it might be nice to have releases as close to openjdk as 
> possible. That way we ensure that when people go looking for the latest 
> openjdk7 update version, they find icedtea7 and don't use the closed 
> source jdk instead. 

I agree strongly with the former, as far as is possible (we don't know
what Oracle actually ship and still ~4% is proprietary, not including
plugin/javaws/javafx).  

I don't think the latter follows from this.  People will go looking on
Oracle's website and find proprietary blobs.  It's not obvious from
Oracle's site that there are FOSS versions and I don't see any way
we can change this unfortunately.  Users need to be strongly encouraged
to update from their distro, not random websites, in general.

> This will also minimize the period in which known 
> bugs are fixed in the (proprietary) openjdk7 update release but the 
> fixes are not available in icedtea7. I know the lack of an explicit 
> openjdk7 release schedule does not help right now, but perhaps this will 
> be addressed soon?
> 

Well u2 coming out today has caught us by a bit of a surprise.  It doesn't
help that pretty much no-one seems to be working on 7, despite all these
claims that we want to switch to it.

The changesets are there in the u2 repository, yet no-one has made any
attempt to start pulling them into IcedTea over the last several months.
Why?

It's about time we started looking at 7 as the main working repository
and 6 as something to backport fixes too.  I know the TCK situation doesn't
yet makes this realistic for enterprise use, but I see Fedora, Ubuntu and
Gentoo all shipping 1.7 packages, which suggests it isn't a blocker there.

> What do others think?
> 
> Cheers,
> Omair

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20111214/6287476a/attachment.bin