Re: [RFC] How to handle external kernel patches in oe the right way?

[Nils Faerber <nils.faerber@kernelconcepts.de>]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

Stefan Schmidt schrieb:
> Hello.
Hi!

> 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.

To add my 0.02€ ;)
I also see both points, for good and for bad.
I have the same situation here currently, I am doing the integration of
a third party board (which will be committed to OE...). The board
manufacturer does it's own kernel port and maintains own patches. But
the manufacturer does not do the OE maintenance.
Including the patch in OE would mean that the patch is stale and once
the kernel maintainer creates a new patch (against the same kernel
version) they would have to send the patch to me so that I can get it
into OE.
So I decided for now to directly pull the patch from their external
source. If they do updates they would be automatically included in a
next build.

For me this calls for something like a stable and development tree, i.e.
the stable tree would include the patch itself and a development tree
would pull from CVS/SVN/externals.

> 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 see a maintenance problem here.
If we have the patches in OE someone has to keep them up to date. Not
impossible, but additional work.

> Comments?

S.a. ;)

> regards
> Stefan Schmidt
Cheers
  nils faerber

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
--


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]