On Tue, Aug 30, 2016 at 05:33:36PM +0200, Arnd Bergmann wrote: > On Tuesday 30 August 2016, Maxime Ripard wrote: > > They used to yes. However, even though I don't really how Linaro works > > internally, my understanding was that being part of Linaro doesn't > > imply that you have engineers assigned. It's probably related to some > > level of membership. > Correct, the higher membership levels require assigning engineers, > but that doesn't mean these engineers work on upstreaming code > of that member company, or even working on the kernel. To be more concrete: the assignees function essentially as contractors for Linaro. They're doing Linaro work on free software products and infrastructure like direct Linaro employees do, they're not working for the member company but rather for Linaro when they're assignees. Linaro does also have landing teams for members at higher levels, these function in the opposite direction and have their work assigned by the members but there's no requirement that this work be upstreaming or even kernel related, it is in some cases (eg, a bunch of the Qualcomm and ST work upstream is being done by Linaro landing teams) but not all. > We do provide all kinds of help to member companies and engineers > to learn everything about upstreaming their code and working with > the communities, and a lot of member companies use that help, but > other members don't. Plus the fact some member companies are large enough that they have several groups working with Linux and in those cases it may only be one of those groups that's joined Linaro and the SoCs people generally see may be from another group. [Specifically in the context of Linaro working on Allwinner SoCs] > > Anyway, like I was saying, no one from Linaro ever contributed > > something meaningful (except some cross-tree patches, and the usual > > "maintainance" patches). > I'm not surprised at all. Most of the kernel work we do in > Linaro is intentionally cross-platform (so it benefits all members > equally), or it is done on those platforms that the members decide > are important upstream. Where possible we'll try to use platforms that already work well upstream rather than trying to do basic upstreaming work.