From: Patrick Ohly <patrick.ohly@intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
Date: Fri, 21 Aug 2015 13:59:24 +0200 [thread overview]
Message-ID: <1440158364.10174.17.camel@intel.com> (raw)
In-Reply-To: <1440153906.12105.233.camel@linuxfoundation.org>
On Fri, 2015-08-21 at 11:45 +0100, Richard Purdie wrote:
> On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote:
> > Allow restricting recipes brought from a layer to a specified list. This
> > is similar in operation to blacklist.bbclass, but instead specifies a
> > per-layer whitelist of recipes (matched by BPN) that are able to be
> > built from the layer - anything else is skipped. This is potentially
> > useful where you want to bring in a select set of recipes from a larger
> > layer e.g. meta-oe.
> >
> > Implements [YOCTO #8150].
> >
> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> > ---
> > meta/classes/whitelist.bbclass | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> > create mode 100644 meta/classes/whitelist.bbclass
>
> I should go on record as having some pretty strong reservations about
> this from a philosophical standpoint.
>
> Why? I think its going to encourage behaviours which will result in a
> decrease in layer quality, particularly for meta-oe.
>
> Taking a simple example, today if someone breaks parsing in meta-oe, its
> quickly known about and multiple people can see and resolve the issue.
> Once people start using this class, many users will simply never
> see/care about parsing breakage in less maintained parts of the layer.
>
> I appreciate Martin will likely notice, however this shouldn't Martin's
> sole responsibility.
>
> Since people's focus will be on to narrow parts of the layer, we'll
> start to see islands which are well maintained/used and islands which
> are not. Worse, just looking at the layer, we won't be able to tell
> which is which.
>
> I'm nervous about anything which pushes responsibility onto already
> overloaded maintainers and encourages behaviour which is a net loss on
> "quality".
I understand that concern. I don't know whether there are currently
users who take the full meta-oe and would stop doing that once this
class gets added. But I know that the inverse is also going to happen:
not using meta-oe at all, starting to use a subset of it with this
whitelist.bbclass. Whether that's a net gain or loss overall I have no
idea.
> Speaking of it, combo-layer was designed to be an alternative way of
> dealing with these issues (more pain to use but causing less of a
> quality impact).
I disagree here. When using combo-layer with filter to pick "desired" or
"supported" recipes, you have the exact same effect as with whitelisting
(only those recipes get tested).
Without filter we have indeed the situation of someone taking the entire
meta-oe and activating it, but that's independent of using combo-layer
or not.
> Sadly, whilst it has seen some improvements, it still
> doesn't handle every operation it would need to make it work for some
> users and isn't widely adopted. I simply don't have the time to go and
> push it forward.
I'm not sure what improvements you have in mind here. The "filter"
mechanism certainly could be enhanced (filtering out a recipe and
adding it later does not work), but that's conceptually the same as
whitelisting.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2015-08-21 11:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 13:34 [RFC PATCH 0/1] Add recipe whitelisting class Paul Eggleton
2015-08-19 13:34 ` [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer Paul Eggleton
2015-08-20 13:47 ` Patrick Ohly
2015-08-21 7:30 ` Huang, Jie (Jackie)
2015-08-24 14:10 ` Patrick Ohly
2015-08-21 10:45 ` Richard Purdie
2015-08-21 10:52 ` Otavio Salvador
2015-08-21 11:59 ` Patrick Ohly [this message]
2015-08-21 17:45 ` Khem Raj
2015-08-21 21:43 ` Otavio Salvador
2015-08-21 22:41 ` Richard Purdie
2015-08-24 11:02 ` Paul Eggleton
2015-08-25 16:20 ` Randy MacLeod
2015-08-25 16:32 ` Paul Eggleton
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=1440158364.10174.17.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
--cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox