[sword-devel] Fwd: Re: Removing XULRunner from oneiric - call for help

[Jonathan Marsden]

I just saw this in the ubuntu-motu mailing list.  Things look bad for
xiphos at first glance.

Is Xiphos going to be able to switch away from xulrunner in time to stay
in Ubuntu Oneiric Alpha 2?

Jonathan

-------- Original Message --------
Subject: Re: Removing XULRunner from oneiric - call for help
Date: Wed, 15 Jun 2011 11:16:44 +0100
From: Chris Coulson <chrisccoulson at ubuntu.com>
To: ubuntu-devel at lists.ubuntu.com, ubuntu-motu at lists.ubuntu.com

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 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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20110619/cbdc6305/attachment.ksh>