On Thu, 11 Nov 2010, Ricardo Salveti wrote:
> On Tue, Nov 9, 2010 at 6:58 PM, Nicolas Pitre <nicolas.pi...@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?
I think that the main reason is that this was much easier to have a
packaged initial release by simply piggybacking on the existing Ubuntu
infrastructure. But John's tree and mine are still separate.
> >> 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.
What extra work do you see? Maybe we could discuss it?
Nicolas
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
