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
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
