[oe] [RFC] How to handle external kernel patches in oe the right way?
Rod Whitby
rod at whitby.id.au
Tue Sep 4 22:21:09 UTC 2007
Stefan Schmidt wrote:
> Due to my work on OpenEZX (http://www.openezx.org) I'm in touch with
> external kernel patches used in OE to build working kernels for
> different Motorola mobile phones.
>
> Talking with Koen about the best way to handle this we have some
> slightly different opinions on this. So we like to get some more
> opinions on this before pinning to a strategy.
>
> Koen like to pull the patches from a known-good rev into oe to have
> them all at one place for less fragile building and tweaking.
>
> I prefer OE to use our svn server with a fixed SRCREV which gets
> updated once a newer version is known good. I'm not a fan of
> duplicating the patches in OE if some small tweaking patches can also
> handle it.
For the ixp4xx-kernel in OE, I pull patches from a fixed known-good rev
in the nslu2-linux.org kernel patches svn. The reason is that it makes
it easier to keep the patches in sync for OE, OpenWrt and Debian (which
all use those patches).
> For bleeding edge building and testing we will create a recipe with
> DEFAULT = -1 anyway.
>
> I'm not totally against Koens approach, just see not much sense, but
> more problems in duplicating the patches in OE. If other people are
> still for it we can of course go that route.
I can see both points of view. As an upstream kernel patch maintainer,
I like to keep a single respository, and then use that in all the
downstream distributions (OE being just one of them) directly. As a
distro maintainer, Koen wants to ensure that OE is not affected by
downtime on the upstream server. Both are valid (but conflicting)
points of view.
Since I'm the ixp4xx-kernel.bb maintainer in OE at the moment, then I
feel that I have the right to choose the way that works for me for that
package :-) Since I also run the upstream svn server, I can ensure that
it has a better uptime than the OE monotone server and wiki ;-)
-- Rod
More information about the Openembedded-devel
mailing list