Hi,
I've already spent way too much on time on this and I really need to be
doing other things, so unless someone steps up now for a particular
application that they care about, the remaining pacakges depending on
xulrunner will be dropped from the archive by alpha 2. This includes:
- xiphos - needs either porting to Webkit (probably a lot of work, but
not sure yet) or switched to using is gtkhtml backend (easy, but gtkhtml
sucks).
- dehydra - already using Spidermonkey, but needs switching to use the
proper lib. Probably just minor build-system changes.
- mongodb - same as dehydra.
- edbrowse - needs porting to Spidermonkey 1.8.5. Based on experience of
doing this already for couchdb, gxine and mongodb, this is probably
going to be a lot of work for the unfortunate victim who ends up doing
this.
The list of remaining work can be found at
https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance
There are still other outstanding items not mentioned here, either
because people really shouldn't bother with them, they have someone
assigned or I still plan to look at them (eg, vlc, fennec and eclipse).
If I've not heard anything by the end of the week, I will assume that
nobody cares about the remaining packages and will start filing removal
requests for them.
Regards
Chris
On Fri, 2011-05-20 at 15:53 +0100, Chris Coulson wrote:
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
