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
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
