[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ubuntu-devel
Subject:    Removing XULRunner from oneiric - call for help
From:       chrisccoulson () ubuntu ! com (Chris Coulson)
Date:       2011-05-20 14:53:53
Message-ID: 1305903241.2047.60.camel () localhost
[Download RAW message or body]

Hi,

At UDS we decided that we are no longer going to maintain XULRunner in
the Ubuntu archive from Oneiric onwards (although, this process already
started at the end of Natty when we did some last minute work to demote
it to universe). The reason for this is that the new rapid release
cadence for Firefox [1] makes XULRunner difficult to support for the
entire life of an Ubuntu release (up to 3 years for a LTS). The new
process doesn't really affect us that much for Firefox - we will still
get security updates at a similar frequency as before, and the changes
between these updates will be mostly incremental. The main differences
are that regular security updates (e.g., the upcoming 4.0.1 => 5.0
update) will bring incremental changes to strings and API, whereas these
previously only happened during major version upgrades (such as the
recent 3.6 => 4.0 upgrade). There will also only be one supported stable
branch in the future, as opposed to the multiple supported stable
branches that we've been used to in the past.

The development cycle is fairly similar to that of Chrome/Chromium.

The reason this makes XULRunner difficult to support is that regular
security updates will be exposed to API changes. Although these will be
incremental, it means that the security team would have to spend a lot
of time every 6 weeks or so transitioning and testing applications to
make sure that they continue working. I know this is the case as I
maintain a binary extension for Firefox which I've already had to make
changes in, to ensure that it continues working on the latest nightly
builds of Firefox from mozilla-central. The alternative to this is to
just backport major security fixes to the version of XULRunner we ship
at release time, but we already know from past experience that this is a
lot of work too, and I don't think anybody is going to volunteer to do
that. I really don't think we have enough bandwidth to pursue either of
these options with an acceptable level of quality.

In addition to this, Mozilla have removed the GtkMozEmbed embedding API
[2], which is still being used by some applications in the archive
(chmsee + anything depending on python-gtkmozembed).

The work to remove XULRunner is being tracked in the
desktop-o-mozilla-rapid-release-maintenance blueprint [3]. When I
started creating work items I realized that we still have quite a lot of
applications in the archive that are using it. Over the next few days
I'm going to be reviewing these dependencies to work out what we should
do with each package. Where applications do have a hard dependency on
XULRunner, I will try to spend time removing that dependency, e.g., by
porting those to an alternative API (such as Webkit).

This is where I would appreciate help from anyone who has a particular
interest in any of the affected applications listed on the blueprint.

Obviously, it would be a shame to lose applications such as chmsee (I
use that, and this is one application which I think is definitely worth
keeping), but I'm not going to spend significant amounts of time working
on applications which aren't that popular or are not very well
maintained.

So, the current plan of action is:
- Browser plugins that are currently depending on xulrunner-dev just to
include the NPAPI headers can depend on firefox-dev for those instead
(eg, packagekit). The alternative is to include a local copy of the
headers instead (eg, Totem does that).
- Browser plugins that are actually using Mozilla interfaces will need
to be modified to not do that (or they will be removed from the
archive). An example is gecko-mediaplayer which uses nsIPrefService to
modify preferences which change the UA string at run-time. This is an
easy fix, as this doesn't even work in Firefox 4 any more (the
preferences it touches were removed).
- Anything using GtkMozEmbed is doomed anyway - they need porting to
another embedding API regardless of what our plans are in Ubuntu. This
includes chmsee, screenlets and lernid.
- Anything just using Spidermonkey can use libmozjs now, as we have a
proper library for this. These should be fairly trivial to fix if they
are already using xulrunner-2.0, as they will probably just require some
build system tweaks. If they are still using xulrunner-1.9.2, then there
may be a significant amount of pain involved, as jsapi changed quite a
bit between the 2 versions.
- Anything that is using XULRunner as a general purpose toolkit (as
opposed to just embedding) is going to be difficult to support, and we
are probably just going to remove those from the archive without
spending any time on them. This includes instantbird.

If anyone has any questions or wants to help out, then please feel free
to grab me on IRC.

Regards
Chris


[1] -
http://mozilla.github.com/process-releases/draft/development_specifics/
[2] - https://groups.google.com/forum/#!
topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
[3] -
https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110520/d9b6d6da/attachment.pgp>

[prev in list] [next in list] [prev in thread] [next in thread]