On Tue, Sep 06, 2016 at 09:25:02AM -0700, Guenter Roeck wrote:
> On Tue, Sep 06, 2016 at 02:34:30PM +0100, Catalin Marinas wrote:

> > Things could be different if fewer entities control the software that
> > gets installed/updated on such hardware. E.g. Google controlling the OTA
> > updates of the Chromebook kernels, they will at some point take a
> > similar hard stance to Red Hat on upstream first, single kernel Image.

> Seems to me that Redhat and Google are in different boats. Chromebooks,
> unlike "standard" PCs, have lots of "custom" hardware, where "custom" means
> hardware for which upstream support is not available. chromeos-4.4 currently

Right, there's a chicken and egg problem - it'd be a lot easier to
insist on this if it were possible to produce a viable product that
way...

> as we can, but it will take a while. Given time constraints, I don't think
> "upstream first" will ever work. Products have to ship and simply can not
> wait for upstream patches to be accepted.

...and you'd be looking at pretty major changes in the market, at least
for the devices shipping bleeding edge silicon.

> Ted was making an excellent point about the complexity of backporting features.
> Out of personal experience, I fully agree. Instead of reducing risk by avoiding
> a newer kernel version, backporting actually adds risk. Maybe it would help to
> educate people about the risks of backporting, and do a better job explaining
> why a new kernel may be a better choice.

People are aware of the risks here - this is where a lot of the pressure
to pull forward onto the newer LTSs comes from.