Micro release exception request for Chromium

Wed Oct 6 14:09:03 BST 2010

Hi,

I would like to request a SRU micro version update exception for the
chromium browser package and its direct dependencies (all part of the
same upstream source tree):
- chromium-browser
- chromium-codecs-ffmpeg
- gyp (google equivalent of autoconf)

A lot has already been said about Chromium. Let me recap and add my own
points.

- chromium first appeared in Lucid in Jan 2010. Since that, i've
prepared and uploaded 10 updates in lucid, 9 in lucid-{security,updates}
(sponsored by our beloved security team), and 15 in maverick. All are in
universe.
As already mentioned by Jamie and Kees, the SRU process choke several
times with fast micro-updates (see below) and as consequence, while
maverick got them all, i had to skip or merge some releases for lucid-*
to prevent users from being exposed to vulnerabilities for too long.

- in Ubuntu, we follow the Upstream Stable Channel (*) as closely as
possible, meaning we preserve the upstream (well QAed) choices such as
build flags and in-source patched libs (with very few exceptions). This
is similar to what we do for Firefox and Thunderbird now.
So the QA upstream does benefits us directly.

(*) Upstream now has 4 channels for Chrome: Stable, Beta, Dev and Canary
(the last only for Windows so far)

- a few month ago, upstream (Google) has decided to increase the pace at
which they create major releases (every 6 weeks), those are not micro
version updates so they are not part of the present request.

- upstream lands security fixes in Chrome Stable quickly (see in annex).
It's usually in batches, but for critical fixes and bad regression
fixes, it could happen very quickly (a matter of days). I usually know
in advance when and why it happens through the upstream security
channels, but not all the details are available beforehand. For example,
the release version number is sometimes pre-announced, but if Google's
QA finds something wrong, their release manager may bump it at the last
minute (so it's difficult to pre-build). Some bugs are not always
visible in the BTS: i have some level of security clearance to view most
security bugs, but obviously not all.

- a few words about my packaging workflow: I get timely notifications of
every single upstream releases [1] and i have efficient ways to prepare
all my packages (using PPAs as a staging platform to get early
feedbacks).
I do that for all channels (automatically for -dev and -beta, manually
for -stable), usually the same day as upstream. All my packaging changes
are made in trunk (that i daily build), and after a while, i land those
changes downward (trunk->dev->beta->stable->maverick->lucid-*) and in
all directions needed [2].

As we have all those builds in PPAs [3] with a lot of users |4], when
something goes wrong, someone usually notices very early on, long before
it reaches stable (and then our official repositories). It proved to
work quite well so far. Upstream told me once that most of the linux
bugs filed in their BTS was coming from ubuntu users, mostly using
ubuntu PPA builds, which has been very useful to them, and also proves
the popularity of ubuntu & ubuntu's PPAs. To further improve the quality
of our bugs, I recently landed some apport hooks, also allowing bug
reports from PPA builds (which should help getting more early
feedbacks).

There's a limitation though: the PPA I use for staging is not native, so
there's no arm build, and then, we discover arm issues at the last
minute: we caught an ARM ftbfs once while going to lucid-proposed
(pocket copied for the native -security ppa), and another time, it was a
runtime regression.

At the request of the security team sponsoring my stable updates, i'm
now trying hard to refrain myself from landing all my packaging changes
into each release. So for SRU, I now land:
- ftbfs fixes (patches, or build-dep bumps mandatory to make it build)
- security fixes or improvements (like the PIE hardening requested by
the security team)
- some user bugs (with documented bug-ids, like workarounds for plugin
crashers)
- eventually some very low risk improvements (such as desktop file
translations)

Everything else will end up in major updates.

Thanks for your attention.

/Fabien

[0] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[1] https://code.edge.launchpad.net/~chromium-team/chromium-browser/channels
[2] http://people.ubuntu.com/~fta/chromium/graphs/
[3] http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[4] http://people.ubuntu.com/~fta/popcon-20101003.png

Annex:

Here are all the versions the upstream Stable Channel received (using [1]):

$ bzr log --line | grep linux/stable | cut -d' ' -f4-
2010-09-24 linux/stable (6.0.472.62 -> 6.0.472.63)
2010-09-18 linux/stable (6.0.472.59 -> 6.0.472.62)   <= sec µ update
2010-09-15 linux/stable (6.0.472.55 -> 6.0.472.59)   <= sec µ update
2010-09-08 linux/stable (6.0.472.53 -> 6.0.472.55)   <= sec µ update
2010-09-02 linux/stable (5.0.375.127 -> 6.0.472.53)  <= major update
2010-08-20 linux/stable (5.0.375.126 -> 5.0.375.127) <= sec µ update
2010-08-11 linux/stable (5.0.375.125 -> 5.0.375.126) <= sec µ update
2010-07-27 linux/stable (5.0.375.99 -> 5.0.375.125)  <= sec µ update
2010-07-02 linux/stable (5.0.375.86 -> 5.0.375.99)   <= sec µ update
2010-06-25 linux/stable (5.0.375.70 -> 5.0.375.86)   <= sec µ update
2010-06-09 linux/stable (5.0.375.55 -> 5.0.375.70)   <= sec µ update
2010-05-26 linux/stable (0.0.0.0 -> 5.0.375.55)      <= 1st stable

for reference, here are the beta releases, which precedes stable
releases (except when beta and stable are aligned and a security update
appears, then beta and stable move at the same time)

$ bzr log --line | grep linux/beta | cut -d' ' -f4-
2010-09-30 linux/beta (6.0.472.63 -> 7.0.517.24) <= stable will jump
2010-09-24 linux/beta (6.0.472.62 -> 6.0.472.63)
2010-09-18 linux/beta (6.0.472.59 -> 6.0.472.62)
2010-09-15 linux/beta (6.0.472.55 -> 6.0.472.59)
2010-09-08 linux/beta (6.0.472.53 -> 6.0.472.55)
2010-09-02 linux/beta (6.0.472.51 -> 6.0.472.53) <= stable jumped to v6 here
2010-08-28 linux/beta (6.0.472.41 -> 6.0.472.51)
2010-08-25 linux/beta (6.0.472.36 -> 6.0.472.41)
2010-08-17 linux/beta (6.0.472.33 -> 6.0.472.36)
2010-08-11 linux/beta (5.0.375.125 -> 6.0.472.33) <= major update
2010-07-27 linux/beta (5.0.375.99 -> 5.0.375.125)
2010-07-02 linux/beta (5.0.375.86 -> 5.0.375.99)
2010-06-23 linux/beta (5.0.375.70 -> 5.0.375.86)
2010-06-03 linux/beta (5.0.375.55 -> 5.0.375.70)
2010-05-22 linux/beta (5.0.375.53 -> 5.0.375.55)
2010-05-21 linux/beta (5.0.375.38 -> 5.0.375.53)
2010-05-11 linux/beta (5.0.375.29 -> 5.0.375.38)
2010-05-04 linux/beta (5.0.342.9 -> 5.0.375.29)
2010-04-07 linux/beta (5.0.342.7 -> 5.0.342.9)
2010-03-25 linux/beta (5.0.307.11 -> 5.0.342.7)
2010-02-27 linux/beta (5.0.307.9 -> 5.0.307.11)
2010-02-18 linux/beta (5.0.307.7 -> 5.0.307.9)