From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
Subject: Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY
Date: Fri, 08 Jul 2011 08:19:57 -0700 [thread overview]
Message-ID: <4E17201D.6040205@linux.intel.com> (raw)
In-Reply-To: <4E14F23C.5050001@linux.intel.com>
On 07/06/2011 04:39 PM, Saul Wold wrote:
> On 07/06/2011 07:06 AM, Paul Eggleton wrote:
>> On Tuesday 05 July 2011 19:37:24 you wrote:
>>> On Tue, 2011-07-05 at 17:31 +0100, Paul Eggleton wrote:
>>>> Is it possible some people are still using PCMCIA/CF cards with this
>>>> hardware in it?
>>>
>>> It's certainly possible, yes. But I don't think that the mere
>>> possibility is a very strong argument for keeping the recipe in oe-core.
>>> Maybe it would be better suited to meta-oe or some BSP layer,
>>
>> You're right, I guess it doesn't really belong in oe-core.
>>
> Phil,
>
> I will take a patch that deletes from here and adds it into the
> meta-extra's layer.
In some cases this is simple enough to do - move one recipe from here to
there. In other cases, not so much. Note that in addition to the removal
of these recipes, Phil also kindly cleaned up kernel.bbclass by removing
a bunch of special casing that was in place for this specific module.
Adding that support to meta-extras is a considerable effort and not
particularly sustainable as more old-and-crusty code is purged from OE.
It is also not likely to be well tested, which makes meta-extra less and
less useful.
We need an exit-path for old-and-crusty code - the git repository has
the history, so if it's needed we can always pull it into meta-extras
and properly test it when we know there is an interest, but if some due
diligence has been performed to determine the code is no longer of any
use, it seems like a lot of effort for very little gain to move any and
all removal of code from oe-core to meta-extras.
Thanks,
Darren
>
> Sau!
>
>> Cheers,
>> Paul
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
prev parent reply other threads:[~2011-07-08 15:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-05 15:52 [PATCH] bluez-dtl1-workaround: remove PRIORITY Phil Blundell
2011-07-05 15:54 ` Phil Blundell
2011-07-05 16:31 ` Paul Eggleton
2011-07-05 17:05 ` Koen Kooi
2011-07-05 18:37 ` Phil Blundell
2011-07-06 14:06 ` Paul Eggleton
2011-07-06 23:39 ` Saul Wold
2011-07-07 14:51 ` Phil Blundell
2011-07-07 15:11 ` Paul Eggleton
2011-07-07 16:06 ` Phil Blundell
2011-07-08 15:19 ` Darren Hart [this message]
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=4E17201D.6040205@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox