Removing XULRunner from oneiric - call for help

Wed Jun 15 10:16:44 UTC 2011

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 --------------
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-motu/attachments/20110615/18371311/attachment.pgp>