Process for providing security updates for chromium-browser

[Chris Coulson]

Hi!

On Wed, 2010-08-18 at 19:21 +0200, Martin Pitt wrote:
> Hello Chris,
> 
> Chris Coulson [2010-08-18 13:38 +0100]:
> > I'm currently working on trying to get Chromium in to main for Maverick,
> 
> For the records, can you please point out why we need to have it in
> main, especially after feature freeze?
> 
Jorge's announcement of postponing Chromium-on-UNE [1] says that it will
still be supported in main for Maverick. In any case, whether we decide
to ship in main now or postpone to Natty, I'd really like to try and get
a working process in place now and have experience of using that process
before we consider shipping it by default.

> On a purely personal perspective, I have started using Chromium a bit
> for an OEM project I'm working on, and I was really amazed about some
> of its shortcomings and bugs (like a lot of crashes on particular web
> pages, or this total misconception of a configuration system). It
> seems to me that they still have some way to go until they reach
> Firefox' maturity. 
> 
> So the reason I ask is that time will obviously work in our favour
> here: in 6 months they might have stabilized their rapid development a
> bit and might make changes to their release process which might be
> more suitable for distros. (Well, I'm optimistic).
> 

I'm not quite as optimistic here. The browser market is currently very
competitive, with a big drive to get features out to end users quickly.
The Chromium release process is already changing [2], to make releases
more frequently and reduce the amount of time users have to wait for new
features. I don't hold out much hope that they will change back to less
frequent releases in 6 months time.

> > - The stable branch receives updates for security fixes at a frequency
> > of approximately every 10 - 14 days (this is based on the current upload
> > pattern for Chromium). 
> > - The time between fixing a security issue in stable and then releasing
> > it to the stable channel is typically less than 1 day (this is the
> > window in which we need to prepare and test the Ubuntu builds). 
> > - New "major" versions are released to the stable channel approximately
> > every 6 weeks. The purpose of these new major versions is to allow new
> > features to trickle in to stable from the beta channel without users
> > having to wait several months for a new version. 
> > - Once a new stable version is released, support for the previous one is
> > ended immediately.
> 
> With a release cycle like this, I think we need to ask ourselves what
> benefit we can still provide by offering it as an Ubuntu package? It
> seems that the only sensible thing we could do under those conditions
> is to keep up with packaging, building, and publishing new versions
> without having any time for sensible testing, and we already
> discussed that we can't provide much testing in the first place.
> 
> Unlike almost (i. e. all except firefox) all of our other packages, we
> can't sensibly support any given version as part of a stable release
> anyway, so at the moment you release, people will have an outdated
> browser and will need to update.
> 
> Under these conditions, IMHO they could just as well download the
> entire thing straight from Google. It's no different bandwidth-wise
> and QA-wise, and it's also in line with what Google actually wants us
> to do (based on UDS discussions with them).
> 
> So I agree with Rick's proposal to just provide an installer for it,
> much like we distribute the flash plugin.

I might be wrong here, but I think Google only distribute their own
binaries for Chrome. I don't think they distribute official builds of
Chromium, which means that we either need to build and distribute it
ourselves or provide an installer for Chrome instead.

Feel free to correct me if I've got that wrong though.

> 
> Martin

Regards
Chris

[1] -
https://lists.ubuntu.com/archives/ubuntu-desktop/2010-August/002603.html
[2] - http://blog.chromium.org/2010/07/release-early-release-often.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/technical-board/attachments/20100818/cbad40f8/attachment.pgp