From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: 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 11:45:06 +0100 [thread overview]
Message-ID: <1440153906.12105.233.camel@linuxfoundation.org> (raw)
In-Reply-To: <d1dcc85512f0c7b9b93f2780048bb9fad8c9da2d.1439991144.git.paul.eggleton@linux.intel.com>
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've talked to several significant users and they all "love" the idea of
this class and plan to adopt it ASAP over existing tools like
combo-layer. I therefore can't see much advantage of not merging the
class as people are going to use it regardless.
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). 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.
So my objection is on record but that is likely about all I can do,
other than hope I'm overly paranoid...
Cheers,
Richard
next prev parent reply other threads:[~2015-08-21 10:45 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 [this message]
2015-08-21 10:52 ` Otavio Salvador
2015-08-21 11:59 ` Patrick Ohly
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=1440153906.12105.233.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--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