This documents summarizes the discussions of the desktop-karmic-browser session at karmic UDS in Barcelona (May 2009) and identifies important goals/actions.
Firefox 3.5 (Xulrunner 1.9.1) will supersede 3.0 (1.9) on the karmic default desktop; the smoothen transition, the Ubuntu MozillaTeam will continue to provide firefox 3.0 and xulrunner 1.9 as universe components for karmic.
A dedicated spec dealing with the firefox 3.5 and xulrunner 1.9.1 transition in main is available at MozillaTeam/Specs/Karmic/Firefox35Transition
Highlighted upstream features taken from the 3.5 beta 4 releasenotes were:
- Improved tools for controlling your private data, including a Private Browsing Mode.
- The ability to provide Location Aware Browsing using web standards for geolocation.
- Support for native JSON, and web worker threads.
- Improvements to the Gecko layout engine, including speculative parsing for faster content rendering.
On branding front, there are no changes planned for karmic. The MozillaTeam will continue to provide the abrowser packages to get an not-branded firefox. In the past demand was communicated to also improve the packaging to allow downstreams to not use a firefox source package name at all. While this is a worthwhile wish, the MozillaTeam does not have the required resources during karmic cycle. Contributions welcome.
Chromium makes good upstream progress on linux 32-bits; the upstream plan was to make a linux build for chrome available in Q2/Q3 2009. The ChromiumTeam provides ubuntu daily builds for hardy, intrepid, jaunty and karmic in the chromium-daily PPA.
Main blockers for chrome becoming the default were identified:
release and security procedures needs discussion and clarification - we need a plan on how to support chromium using the current ubuntu means without sacrificing security or stability. Main points to clarify are:
- Stable Release policies: will there be stable release branches?
- Security Release policy: will there be coordinated security releases? Will embargoed communication take place in a fashion that distributors have a chance release in sync with chrome? Will there be a security group just like mozilla's or will chromium team use vendor-sec? If there are stable branches, how frequent are stable branches cut and how long will they get security support?
upstream source size - the size of the currently (Jun 09) required tarball (which is aggressively stripped down) is about 180MB using bzip2 compression. There are about 3.2G of files in a svn checkout. This would make chromium one of the largest code base in the archive, which obviously has some negative consequences:
- higher bar for contributors - huge code bases are prone to make it hard to build a community around them. The blockers are time and resources (like bandwidth, hardware/CPU/MEM constraints)
- duplication of code in the archive puts higher load on security team and bug triage and is considered bad practice - to some degree it will also have a negative impact on the footprint, because shared libs are not shared.
non ia32 architectures are not supported - will chromium be available on architectures other than ia32 at some point? Not having other architectures somewhat makes it hard for chromium to become the default in ubuntu. (See: http://dev.chromium.org/developers/design-documents/64-bit-support)
Webkit will gain more importance for ubuntu during the karmic cycle as we aim to migrate xulrunner 1.9 embedding API rdepends to Webkit instead (see MozillaTeam/Specs/Karmic/Firefox35Transition for details).
Highlights of this transition are:
- epiphany using Webkit by default (current blocker: accessibility)
- no rdepends on xulrunner gecko embedding api in main
- start upstream discussion on stable/security release procedures (see above)
- file upstream bugs about support for system libs for third_party libs
- most likely not in the archive for karmic
migrate most xulrunner rdepends to Webkit (see: MozillaTeam/Specs/Karmic/Firefox35Transition)
- understand upstream procedures for stable release updates and coordinated security updates.
- ensure most epiphany profile data gets migrated to epiphany-webkit (e.g. passwords/cookies/bookmarks/history)