The desktop-karmic-browser spec was an informational and discussion session during Karmic UDS in Barcelona (May 2009)
This documents summarizes the session and gives a few mostly non-technical actions identified.
Status Quo in Karmic
Firefox 3.5 will supersede 3.0 on the desktop in karmic; the Ubuntu MozillaTeam will continue to provide firefox 3.0 and xulrunner 1.9 as universe components for karmic. 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.
Support for new web technologies such as: HTML5 <video> and <audio> elements,
The dedicated spec just dealing with the firefox 3.5 and xulrunner 1.9.1 transition in main is available at MozillaTeam/Specs/Karmic/Firefox35Transition
Chromium makes good upstream progress on linux 32-bits; the upstream plan was to make a linux build for chrome available in 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 distribution procedures without sacrificing security or stability. Main points to understand 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 required tarball is more than 300MB using bzip2 compression. There are about 4G of files in an unpacked tree. This would make chromium 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 bandwith, hardware/CPU/mem constraints)
- duplication of code in the archive puts higher load on security team and is considered bad practice. To some degree it will also have a negative impact on the foodprint, because shared libs are not shared anymore.
non ia32 architectures are not supported - will chromium be available on architectures other than ia32 at some point? Not having other architectures somewhat disqualifies chromium from becoming a default on ubuntu.