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

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

[Stefan Schmidt]

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

Hello.

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

Comments?

regards
Stefan Schmidt

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Rod Whitby]

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

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

[Nils Faerber]

[-- 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 --]

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

[Richard Purdie]

On Tue, 2007-09-04 at 22:29 +0200, 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.

Personally I agree with this in principle, I've never liked maintaining
kernel patches in OE directly either.

Cheers,

Richard

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

[Justin Patrin]

On 9/5/07, Nils Faerber <nils.faerber@kernelconcepts.de> wrote:
> 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.
>

That's not really true. OE won't rebuild the kernel unless the PR has
been changed. When they update their patch they still need to tell you
so that you can update the PR in OE.

-- 
Justin Patrin

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Tue, 2007-09-04 at 22:29 +0200, 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.
> 
> Personally I agree with this in principle, I've never liked maintaining
> kernel patches in OE directly either.

I'm having issues with crap like do_prepatch. Patches are only applied by patch.bbclass,
not some hand written voodoo <period>.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG3unjMkyGM64RGpERAnXQAJwLwfJkgpwmGwxt8gn3BkiGvCIRKQCfWfEn
uxozGirs/hyk2v6Npas/Kis=
=KLS+
-----END PGP SIGNATURE-----

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

[Dr. Michael Lauer]

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Richard Purdie schreef:
>> On Tue, 2007-09-04 at 22:29 +0200, 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.
>> 
>> Personally I agree with this in principle, I've never liked maintaining
>> kernel patches in OE directly either.

> I'm having issues with crap like do_prepatch. Patches are only applied by patch.bbclass,
> not some hand written voodoo <period>.

Very well. If it annoys you so much, feel free to enhance patch.bbclass to
deal with upstream series files while retaining OE-added patches to it.

Until then, I think we shouldn't make life more complicated for the
actual upstream developers just because of going a bit too far wrt. to
our principles.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dr. Michael Lauer schreef:
> Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
> 
>> Richard Purdie schreef:
>>> On Tue, 2007-09-04 at 22:29 +0200, 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.
>>> Personally I agree with this in principle, I've never liked maintaining
>>> kernel patches in OE directly either.
> 
>> I'm having issues with crap like do_prepatch. Patches are only applied by patch.bbclass,
>> not some hand written voodoo <period>.
> 
> Very well. If it annoys you so much, feel free to enhance patch.bbclass to
> deal with upstream series files while retaining OE-added patches to it.

Like I said *many* times before, the ezx patch script does that.

> Until then, I think we shouldn't make life more complicated for the
> actual upstream developers just because of going a bit too far wrt. to
> our principles.

How many times to I have to offer to do the work for you!?!?!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG3whDMkyGM64RGpERAliMAJ9JEf0KSB1/nZdLbB/9eKV1zKzpUgCdHvj2
iXImgX7irQZKoeFb5hrfecM=
=/SB3
-----END PGP SIGNATURE-----

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

[Richard Purdie]

On Wed, 2007-09-05 at 20:52 +0200, Dr. Michael Lauer wrote:
> Koen Kooi wrote:
> > Richard Purdie schreef:
> > I'm having issues with crap like do_prepatch. Patches are only
> applied by patch.bbclass,
> > not some hand written voodoo <period>.
> 
> Very well. If it annoys you so much, feel free to enhance patch.bbclass to
> deal with upstream series files while retaining OE-added patches to it.
> 
> Until then, I think we shouldn't make life more complicated for the
> actual upstream developers just because of going a bit too far wrt. to
> our principles.

I'm afraid I'm with Mickey here. I don't like the way this "prepatching"
works and I think its pretty ugly but I can understand why people are
doing it. I'd like to see a better solution but until then what they're
doing allows them to develop effectively which is what we're supposed to
be about.

Cheers,

Richard

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

[Graeme Gregory]

On Wed, Sep 05, 2007 at 08:52:21PM +0100, Richard Purdie wrote:
> I'm afraid I'm with Mickey here. I don't like the way this "prepatching"
> works and I think its pretty ugly but I can understand why people are
> doing it. I'd like to see a better solution but until then what they're
> doing allows them to develop effectively which is what we're supposed to
> be about.
> 
Maybe if I get some free time around october I might suggest enhancing
the fetcher/patcher so that any URL can have a

http://blah.com/patches.gz;patchseries=1
svn://wibble.com/branchs/smoo/;patchseries=1

And it does the right thing.

Or am I going backwards?

Graeme

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

[Dr. Michael Lauer]

Graeme Gregory wrote:
> On Wed, Sep 05, 2007 at 08:52:21PM +0100, Richard Purdie wrote:
>> I'm afraid I'm with Mickey here. I don't like the way this "prepatching"
>> works and I think its pretty ugly but I can understand why people are
>> doing it. I'd like to see a better solution but until then what they're
>> doing allows them to develop effectively which is what we're supposed to
>> be about.
>> 
> Maybe if I get some free time around october I might suggest enhancing
> the fetcher/patcher so that any URL can have a

> http://blah.com/patches.gz;patchseries=1
> svn://wibble.com/branchs/smoo/;patchseries=1

I like that a lot.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

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

[Dr. Michael Lauer]

Koen Kooi wrote:
>> Very well. If it annoys you so much, feel free to enhance patch.bbclass to
>> deal with upstream series files while retaining OE-added patches to it.

> Like I said *many* times before, the ezx patch script does that.

As far as I can see this script just dumps out SRC_URI lines. Which
means everytime someone commits a new revision of the patch. Even if
it's not me that needs to do it, I don't like it because it's a manual process.

>> Until then, I think we shouldn't make life more complicated for the
>> actual upstream developers just because of going a bit too far wrt. to
>> our principles.

> How many times to I have to offer to do the work for you!?!?!

Look, I really appreciate this and thanks for that, however I think
there is something seriously wrong in principle if we start treating
OE as a patch archive. This is semi-ok for when we don't have control
over upstream, but it just shouldn't be that way in general.

I think we talked long enough about that, there are different views
here and I doubt that one of us will be able to convince the other.

It was about time we ultimately disagree over an issue. Now let's see
whether we have a working process to deal with such a situation :)

The options:

a) vote for one solution and go with the winner
b) a compromise and make one "stable" bb with patches in OE and one
"unstable" bb that drags patches from upstream.

Eventually we may as well find a suitable compromise in XorA's suggested
patch that makes the fetcher and the patcher know about a quilt series
file, but let's talk about this when it's there.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de