Ubuntu ARM and the linaro kernels

[John Rigby]

On Mon, Nov 15, 2010 at 4:28 AM, Loïc Minier <loic.minier at ubuntu.com> wrote:
>  Folks, I think this thread is circling a bit back to itself, perhaps
>  summarizing where we stand and what problems we're trying to solve
>  would help?
>
>
>  * Linaro integrates its kernel tree into Ubuntu for two reasons:
>   - because Linaro uses Ubuntu as a base to build its own derived
>     images (out of Ubuntu)
>   - because Linaro wants its kernel shipped/available in distributions
>     such as Ubuntu/MeeGo/whatever for mutual benefit of the distro and
>     of Linaro.  For instance, Ubuntu users could install this kernel
>     instead of the official Ubuntu one, or Ubuntu could build images
>     from this kernel (as proposed in the original email).
>
>  * there are currently the following *three* trees for the Ubuntu Linaro
>   kernel packages to happen (for maverick):
>   - git://git.linaro.org/kernel/linux-linaro-2.6.35.git -- upstreamish
>     tree maintained by Nicolas, based on upstream git tree with patches
>     relevant to Linaro merged in; the Linaro Kernel
>   - git://git.linaro.org/ubuntu/linux-linaro.git -- Ubuntu-ish tree
>     for the linux-linaro source package in Ubuntu or in Linaro PPAs
>     maintained by jcrigby, based on the Linaro Kernel tree with
>     packaging and the Ubuntu stuff ("Sauce") merged in
>   - git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git linaro branch --
>     pretty much the same as jcrigby's tree maintained by the Ubuntu
>     kernel team; it's mostly a copy of jcrigby's tree when it gets
>     uploaded to Ubuntu, unless the Ubuntu kernel team has to do any
>     minor adjustments/fixups before upload; it exists only because
>     jcrigby can't upload and because /ubuntu is restricted to the
>     official Ubuntu Kernel Team
>
>  So what problems / questions are we trying to solve?
>  * security support: Linaro isn't in the business of long-term security
>   support of its trees, however I understand that it wouldn't be a big
>   problem to simply add the *Ubuntu* linux-linaro package and the
>   kernel.ubuntu.com git tree to the list of packages/trees which get
>   security updates from the Ubuntu Security Team, especially if the
>   Ubuntu ARM Team moves to this package/tree as their base for some
>   images
>  * for Linaro, the Ubuntu Sauce stuff doesn't add any much value and is
>   a distraction (causes more merge efforts, might cause extra bugs
>   etc.)
>
>
>  Is this a fair summary?  Did I miss anything?
>
>
>  I am not sure I understand the point of contention with the Ubuntu
>  Sauce stuff; is it causing problems to Linaro right now?
>   Linaro GCC is released in source form and then integrated in the
>  Ubuntu gcc-4.x packages which have tons of patches added on top; this
>  is not ideal for Linaro Toolchain WG, but it's part of the process to
>  check whether bugs do apply to the pristine Linaro source, just like
>  you need to test a pristine upstream GCC or Linux when reporting bugs
>  upstream.
>
>  There are definitely things we could do to improve the Ubuntu Sauce:
>  * split this stuff more; e.g.:
>   - packaging goes in one tree (I think this is already split out?)
>   - patches which come from upstream or were acked upstream go into
>     another tree
>   - patches which are Ubuntu specific such as AUFS go into one or
>     multiple separate trees
>  * we could review the current sauce stuff and only merge in features
>   which are really needed for Linaro images and Ubuntu ARM images; aufs
>   doesn't seem to be needed anymore for instance?  Maybe this makes
>   things more complex for little gain though
>  * we could stop merging patches from upstream from Ubuntu, and have
>   them flow in via Linaro instead; again, maybe this makes things more
>   complex for little gain
>
>
>  My opinion is that the current approach is okay modulo two things:
>  - we should drop one of the two packaging trees; the
>   linaro / jcrigby versus kernel.ubuntu.com split is useless
>  - we could provide pristine kernel builds, built from the Linaro Kernel
>   directly and without any Ubuntu Sauce
>   . in fact these exist already, they just aren't tested and they use a
>     random config: http://hudson.dooz.org/
>   . if we want Linaro Kernel .debs instead of standalone zImage/uImage,
>     we could do something like
>     https://wiki.ubuntu.com/Kernel/MainlineBuilds
>
>
>  Proposed plan:
>  * Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok
>   to base Ubuntu ARM images on linux-linaro tree as constructed
>   currently
I can't speak for the Ubuntu ARM folks but I believe their main concern was if
I stopped including Ubuntu Sauce.
>  * John to request upload permissions for linux-linaro only and to
>   request commit rights to ubuntu/ubuntu-$release.git for the linaro
>   branch only
The plan proposed at UDS was for Steve Langasek to take over the roll of
linux-linaro upload sponsor.  He would replace Tim G in this role.  Perhaps
we could try this for one cycle then consider the idea of me uploading
after that.
>  * if someone cares about limiting the Ubuntu Sauce which goes into the
>   linux-linaro Ubuntu package which goes into Linaro images, then that
>   someone ought to start discussion on splitting and limiting the Sauce
>   which goes into the linaro branch with the Ubuntu Kernel Team; I
>   don't think this fundamentally holds up anything though
The easiest way to include Ubuntu Sauce is to include all of it.  It rarely
causes merge conflicts and I can't think of an instance where it has
caused breakage for linux-linaro so I suggest we just keep including it all.
To include a subset would require someone to decide what subset and
that would be extra work.
>  * if someone cares about providing better vanilla Linaro Kernel builds,
>   e.g. .debs, then that someone ought to start some spec on providing +
>   testing these builds -- I'm happy to help here  :-)
>
>
>
>   Cheers,
> --
> Loïc Minier
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>