Process for providing security updates for chromium-browser

[Jamie Strandboge]

On Wed, 2010-08-18 at 13:38 +0100, Chris Coulson wrote:
> I would like permission to use a similar process for Chromium too.
> 
I too see this as beneficial, but do want to mention that the current
practice with chromium-browser is (essentially) to recompile whatever is
in the development release of Ubuntu on the stable releases. Eg,
whatever is in maverick gets the distribution and version tweaked and
then we send it to lucid-proposed, etc. I would like to see this
tightened up such that we have specific branches for debian/ for each
release so that the packaging is not changing all the time. Changes to
packaging then require an SRU (just like with Mozilla) unless the new
version of the browser from upstream requires something different in the
packaging.

> The obvious risk to this is that we currently enjoy quite a large window
> in which we can test Mozilla security updates to ensure that they are
> regression free. This window is virtually non-existant for Chromium once
> we factor in the amount of time it takes to actually build it, so we
> will be mostly at the mercy of upstream QA for security updates.

While this is a valid point, I contend we are really at the mercy of
upstream QA anyway. Ie the QA we do on our browsers is only for major
breakage. This is due partly because of resources, because our community
testers are only doing anecdotal testing and because we don't have
access to upstream's security bugs to regression test anyway. The lines
of code for browsers is so huge and the potential regressions so subtle
that our official testing only covers big things like 'does JavaScript
work?', 'does the flash plugin still work?', 'does SSL work?', etc
(because browsers are so complex, this turns out to be a rather long
list as it is). Put another way, what I ask myself before publishing a
new version of a browser is "for each release for each supported
architecture that I can test (ie, i386 and amd64) am I reasonably
confident that this update won't break most users in a significant
way?". With Mozilla I feel this is ok because I know that they have a
tremendously massive internal test suite that is extremely
comprehensive, because most regressions will not be OS specific, and
that upstream QA will have caught most functional regressions and fixed
them before we see the build.

Considering this and Chris' point, what kind of QA does Google have for
chromium-browser? Providing the same level of testing we do for Firefox
on chromium-browser may be enough for now since chromium-browser is in
universe, but certainly going forward and thinking about the MIR
process, it would be good to know upstream's QA practices. 

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/technical-board/attachments/20100818/0cae4fa7/attachment.pgp