FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 05-20-2011, 02:53 PM
Chris Coulson
 
Default Removing XULRunner from oneiric - call for help

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
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 06-15-2011, 10:16 AM
Chris Coulson
 
Default Removing XULRunner from oneiric - call for help

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

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 06-16-2011, 05:40 PM
Dustin Kirkland
 
Default Removing XULRunner from oneiric - call for help

On Wed, Jun 15, 2011 at 5:16 AM, Chris Coulson <chrisccoulson@ubuntu.com> wrote:
> 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:

Hi Chris,

Thank you very much for the heads-up.

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

I can't speak for any of the other packages that you mentioned, but
MongoDB is still quite important to the Ubuntu Server Community, as
it's about to become a dependency of the CloudFoundry PaaS packages.

I know that you and Brian (on CC) have had a private conversation
about this, but just for the rest of -devel's and -motu's awareness,
Brian is in the process of migrating the mongodb package build to use
the replacement library.

Thanks!
Dustin

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

Please don't remove mongodb, per above ;-)

Thanks,
--
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 08:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org