All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: Using the OpenEmbedded metadata to build Distributions
	<openembedded-devel@openembedded.org>
Subject: Re: [RFC] How to handle external kernel patches in oe the	right way?
Date: Wed, 05 Sep 2007 21:49:23 +0200	[thread overview]
Message-ID: <46DF0843.3090409@student.utwente.nl> (raw)
In-Reply-To: <1434447296.20070905205215@vanille-media.de>

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



  reply	other threads:[~2007-09-05 19:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04 20:29 [RFC] How to handle external kernel patches in oe the right way? Stefan Schmidt
2007-09-04 22:21 ` Rod Whitby
2007-09-05 11:48 ` Nils Faerber
2007-09-05 17:36   ` Justin Patrin
2007-09-05 16:58 ` Richard Purdie
2007-09-05 17:39   ` Koen Kooi
2007-09-05 18:52     ` Dr. Michael Lauer
2007-09-05 19:49       ` Koen Kooi [this message]
2007-09-05 22:53         ` Dr. Michael Lauer
2007-09-05 19:52       ` Richard Purdie
2007-09-05 21:14         ` Graeme Gregory
2007-09-05 22:45           ` Dr. Michael Lauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46DF0843.3090409@student.utwente.nl \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.