If Icedtea-web is the plug-in component for OpenJDK upstream, its name should be openjdk-plugin !
Andrew Hughes
ahughes at redhat.com
Wed Apr 18 06:14:35 PDT 2012
----- Original Message -----
>
>
>
> On Tue, Apr 17, 2012 at 15:44, Deepak Bhole < dbhole at redhat.com >
> wrote:
>
>
>
> No problem. For the record, I've opened a bug against yum:
> https://bugzilla.redhat.com/show_bug.cgi?id=813432
> Thanks!
> This is the first step towards a (partial) solution.
>
> Of course, it'd be a universal solution if Icedtea-web would be
> integrated into OpenJDK or renamed OpenJDK-plugin. ;-)
>
As has already been stated by Andrew Haley, the plugin was split apart
from the main IcedTea builds (packaged as java-1.x.x-openjdk) for technical
reasons, so integrating it into OpenJDK would be a backwards step that would
make things even worse than before.
This has far more effect on the end-user experience than getting the plugin
installed to begin with (a one-time effort). Take the scenario that a bug
is found in the plugin. There are three different processes by which the patch
could get out to end-users, depending on whether the plugin is independent,
part of IcedTea (as it was prior to March 2011) or part of OpenJDK.
1. Plugin is independent
The patch is added to the source code base and a release made, which then gets
packaged for your favourite distribution. The rebuild is trivial as the plugin
takes little time to build. The impact on users is minimal as only those with
the plugin installed get an update and that update is only for the plugin.
This can all happen within the space of about a week (and that's mostly to give
everyone appropriate notice of the upcoming release).
2. Plugin is part of IcedTea
The patch is added to the source code base, but making a release means making a new
release of IcedTea in its entirety. Such a release has to be worthwhile for all
JDK users, not just plugin users. It's more likely that the fix will be backported
to an existing release branch and a minor release made, to avoid a full major release
for just a plugin issue, but this still takes time and effects more people. The
rebuild involves building the whole JDK again which takes about 30 minutes even on
fast x86_64 boxes, never mind other architectures like ARM. All users get a JDK update
regardless of whether they use the plugin or not. The amount of time this takes depends
on the current status of an IcedTea release, but it's very unlikely to be as quick as 1
in our experience.
3. Plugin is part of OpenJDK
Any patches have to be contributed to Oracle under the OCA and approved by their engineers
to get into the 8 and 7 update trees rather than just our own tree. The release cycle is
out of our control and determined by Oracle. The rebuild and packaging process is much
the same as for 2. Time taken is even more variable, as it depends on the OpenJDK release
cycle and availability of upstream approval, but much longer than for 1.
Hopefully, you can see from the above why we chose 1 in order to give our users fixes as
speedily as possible. This long-time maintenance issue trumps initial install in terms
of ongoing user experience.
As to just renaming it "OpenJDK-plugin", we don't do this because it isn't part of OpenJDK,
and for much the same reasons "The GIMP" (which is a far worse name) isn't called "Photoshop"
and every fast food outlet isn't called "McDonalds", just because those names are more widely
recognisable.
Thanks for your feedback on the issues with installing the plugin and hopefully something can
be resolved in the packaging for Fedora. This does seem to largely be a packaging issue, as
Debian and Gentoo both seem to handle this issue already, via "Recommends" and a post-dependency
respectively.
> Thanks again
> FC
>
--
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
More information about the distro-pkg-dev
mailing list