Ubuntu ARM and the linaro kernels

[Ricardo Salveti]

On Tue, Nov 9, 2010 at 6:58 PM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Tue, 9 Nov 2010, Oliver Grawert wrote:
>
>> hi,
>> Am Montag, den 08.11.2010, 15:46 +0000 schrieb Jamie Bennett:
>> > > * linaro kernels used in ubuntu ARM would need to move to the
>> > > supported
>> > > package set (main) which makes them fall under all freeze restrictions
>> > > the kernel team sets for ubuntu (only SRUs post kernel freeze, patches
>> > > and changes all need to go through the ubuntu-kernel mailing list etc)
>> >
>> > I think we can deal with the via the SRU process. We have already been
>> > using the SRU process this cycle for kernel changes so its a non-issue.
>> well, the kernel freeze and SRU process would happen for you guys a lot
>> earlier due to that, thats why i wanted to bring it up ...
>
> While I see lots of goodness in trying to reduce this duplicated effort,
> I think there is still a slight disconnect between Linaro's and Ubuntu's
> goals for their respective kernels.  While Ubuntu should focus on the
> greatest support to enhance the user experience, Linaro is there to
> promote support of the ARM architecture in general through consolidation
> towards the mainline kernel.
>
> This means that, for example, that the Linaro kernel will not merge
> anything with no hope of ever being accepted upstream, including stuff
> like a single patch adding 45 thousand lines of code in one shot to
> support proprietary 3D graphics libraries.  Now that we have a corporate
> backed entity to promote upstream contributions for the greater benefit
> of all members, we should not weaken this principle by carrying
> proprietary drivers with a dead future which would send a wrong signal.
>
> However, the Ubuntu kernel has little choice but to merge those
> proprietary drivers as the unfortunate fact is that there is simply no
> alternative (yet) to produce a viable 3D user experience.  And I'm
> afraid that this burden has to be carried on the Ubuntu side.  Let's
> hope that the reduced engineering effort on the Ubuntu side due to the
> work now undertaken by the Linaro team will compensate for this
> continuing burden.

That's understandable. Now the question is why John is maintaining and
packaging a tree that also incorporate the Ubuntu sauce on it?

> Linaro is also driving a work force which should serve the greater ARM
> Linux ecosystem, including Ubuntu on ARM of course, but other entities
> as well.  Therefore the Linaro process cannot always be tied to the
> Ubuntu process.  This means that Linaro may not always follow the exact
> same schedule as Ubuntu, and things like Ubuntu sauce patches and/or
> kernel configs might not make sense in all Linaro contexts.

I also agree on this one. I believe that now that Linaro is getting
more popular and used by other entities, makes no much sense in
maintaining something that will be used by Ubuntu. Only a reference
and maintained tree would probably be enough in case distros want to
incorporate it.

>> one option i see is that we use the linaro branches as base and add all
>> distro kernel specifics on top here, but thats something the kernel team
>> has to agree to since they will have to be the ones doing that work (and
>> i personally cant really judge how much work this is for them).
>
> I'm afraid this might have to be the case.  However, Git is pretty
> powerful and effective to carry such a task.

This will probably be the case. At least it's the one that makes more
sense in the Linaro's perspective.

Now the question is, are we sure that this will actually reduce the
workflow for the Ubuntu kernel team? I know in case of Omap 3 it was
one additional flavor, but was somehow OK because it follows upstream
and they are already used with it. Having the Linaro tree as reference
instead of upstream will probably produce a better ARM kernel, but it
seems that it'll give more work to the kernel team, instead of making
things easier.
-- 
Ricardo Salveti de Araujo