| 1 |
On Wed, Jan 16, 2013 at 4:59 AM, Rich Freeman <rich0@g.o> wrote: |
| 2 |
> On Wed, Jan 16, 2013 at 6:54 AM, Alexis Ballier <aballier@g.o> wrote: |
| 3 |
>> On Tue, 15 Jan 2013 21:10:12 -0800 |
| 4 |
>> ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
| 5 |
>>> |
| 6 |
>>> What when chromium upstream uses code more recent than latest ffmpeg |
| 7 |
>>> release and it doesn't compile against latest release? |
| 8 |
>> |
| 9 |
>> Blame them, it's stupid to break support for the latest release. |
| 10 |
>> Usually, it's quite trivial to maintain compatibility and you should |
| 11 |
>> probably lobby upstream to get this as a rule, it'd make life simpler |
| 12 |
>> for everyone. Or just patch releases not to use too bleeding-edge code |
| 13 |
>> (see mplayer for example). |
| 14 |
> |
| 15 |
> While I agree in principle, that is much easier said than done. I |
| 16 |
> think upstream is more likely to consider the concept of a linux |
| 17 |
> distro broken than their code. |
| 18 |
> |
| 19 |
> The unpacked chromium distfile is 1.1G, of which 694M is third party |
| 20 |
> source-code. The chromium team has done an excellent job of disabling |
| 21 |
> much of that, but the upstream attitude clearly is to cherry-pick |
| 22 |
> their dependencies. This is pretty typical for Google projects from |
| 23 |
> what I've seen - ChromeOS basically is a fork of Gentoo with many |
| 24 |
> packages being fairly dated, and Android does just about everything |
| 25 |
> its own way, typically releasing third-party code into production |
| 26 |
> before any upstream packages have access to it. |
| 27 |
|
| 28 |
Google generally prefers agility. Particularly when machines have gobs |
| 29 |
of memory (so bundling is not as big of a deal as it was previously) |
| 30 |
and they can staff security fixes for all their bundled libs. This is |
| 31 |
quite a pervasive attitude there. Coming from a distribution |
| 32 |
background it can be weird to see the different priorities (and |
| 33 |
terrible systems that build the packages that work on $DISTRO, ew.) |
| 34 |
|
| 35 |
-A |
| 36 |
|
| 37 |
> |
| 38 |
> Of course, we should encourage upstream to improve its practices. I |
| 39 |
> just wouldn't count on it, so I think we need to give the chromium |
| 40 |
> team discretion on just how much patching they think they can handle. |
| 41 |
> They're obviously pretty good at it already. |
| 42 |
> |
| 43 |
> Rich |
| 44 |
> |
Archives