• Blueprint: desktop-lucid-new-firefox-support-model

• Contributors: Alexander Sack

• Packages involved: firefox, xulrunner and its reverse (build) dependencies

Summary

This spec is about reviewing the current support model for firefox in stable ubuntu releases. Goal is to identify tasks and procedures that are work intensive or incur risk while not giving appropriate value for the distributions. For those tasks and procedures alternatives are presented that involve rolling major version updates to stable ubuntu releases.

This spec covers two parts:

1. ensure that from lucid onward updating firefox versions to the next stable branch in security updates does not involve huge porting efforts
2. minimize regressions in existing ubuntu releases when updating firefox/xulrunner and friends to the latest supported upstream branch

Rationale

In short or long term firefox is expected to move to a changed branch policy; this most likely will involve even shorter support for stable release branches. Numbers discussed are: 4-6 weeks for minor security/stability updates and 4-6 month for major version updates; at the same time security/stability support for old branches will be dropped.

In consequence, using our "old" way of backporting patches for firefox becomes more and more unfeasible. The risks of incurring distribution regressions is high, while the win is debatable.

Design - New releases

The change in support model suggested by this spec involves changes to various areas outlined in separate sub sections below. On top this spec defines how a switch to this new support model for existing ubuntu releases can be accomplished in a diligent fashion.

Major version upgrades instead of backporting

Instead of backporting patches to EOL branches, ubuntu releases will be updated to the next still supported firefox branch once the current firefox branch of that ubuntu release goes EOL upstream. This will reduce the workload on developer and QA side considerably and reduce the risk of incurring additional regressions due to backporting bugs.

Use in-source libraries rather than system libs

enabling system libs is not officially supported upstream and supporting this caused notable work in the past while sometimes leading to a suboptimal user experience due to version variants in the ubuntu released compared to the optimize version shipped in the firefox upstream tarballs.

Reduce in-archive reverse dependencies to a minimum

Not backporting security fixes, but upgrading to new firefox branches would come with a considerable effort for backporting reverse dependencies in the archive. To keep this approach sustainable the ubuntu archive needs to be reviewed and only the most important packages can be kept.

Move extensions to a PPA

Extension packages are useful, but the archives stable support properties doesn't fit their release policies and user expectations well. Hence, extensions should be moved to a PPA which then can be made available prominently in the software center or even through the firefox extension manager at some point.

Design - stable ubuntu releases

Stable ubuntu releases, will require a full security coverage in main. This also includes the xulrunner-1.9.1 packages. Assuming that xulrunner 1.9.1 cannot be kept secure we will need to update xulrunner to latest branch in much the same way as suggested for firefox.

Eliminate embedders

non-trivial gecko embedders must be eliminated in stable ubuntu releases; this needs to happen by moving them to an existing webkit variant; if no webkit port exists, porting them to next xulrunner branch needs to be done.

port plugins

Plugins need to be ported in time to the new firefox/xulrunner major version. Usually this should work well, however, there are potential issues with java in particular.

upgrade extensions

Extensions that ship binary components must be updated to latest upstream version. For extensions that are hosted on AMO (addons.mozilla.org) and do not have binary components we need to ensure that extensions get updated to the profile version. For that we ship an install.rdf in an otherwise empty extension package with a special hint that triggers a system to profile upgrade on next firefox start.

Implementation - Lucid

• produce a firefox package that does not use system-libxul
• remove as many system libs from firefox build as possible; revert to in-source libs where possible
• assemble a table of reverse dependencies
  • prioritize reverse dependencies
  • mark packages that we cannot or do not need to support for removal
  • mark packages that use the gecko embedding API
  • mark and categorize extensions in archive:
    • extensions with binary components
    • extensions without AMO (addons.mozilla.org) support
    • arch-independent extensions available from AMO (addons.mozilla.org)
• take decision on support/removal/porting to webkit on all individual packages
• decide on demotion vs. droppage of xulrunner-1.9.x from the archive.
• port/implement/remove packages as decided

Implementation for existing releases

• prepare firefox major version upgrade; base on the lucid branch
• assemble tables for reverse dependencies for all supported ubuntu releases
  • prioritize reverse dependencies
  • mark reverse dependencies that are not exposed to unsafe content and hence do not need to be upgraded/replaced
  • mark packages that we cannot or do not need to support
  • mark packages that use the gecko embedding API
  • mark extension packages in the archive for each individual release:
    • extensions with binary components
    • extensions without AMO (addons.mozilla.org) support
    • arch-independent extensions available from AMO (addons.mozilla.org)
• take decision on support/removal/porting to webkit on all individual packages
• backport karmic/lucid packages for reverse dependencies that moved to webkit or something else

Implementation background

Moving to this new support model has some implications on what packages can be accepted in the ubuntu repository in future:

• xulrunner embedders must be removed or replaced with webkit backend alternatives
• xulrunner npapi plugins should be maintainable accross multiple firefox branches and hence can still be in the archive
• xulrunner/firefox extensions must be reduced to the very minimum in archive. Main reason for archive inclusion should one of the following:
  1. required for an ubuntu image or essential use case
  2. has binary components - rational is that upstream binary components usually do not support amd64 or other supported ubuntu archs.
  3. considered useful and is not distributed in AMO (addons.mozilla.org).

References/Progress

• this section is used to extend the specs with content created as part of this spec. References to wiki pages for the reverse dependency review will be added et al.