[OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer

[Paul Eggleton]

On Friday 21 August 2015 11:45:06 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 at 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.

I appreciate the concern, but I have to be honest, I don't see this as being a 
problem with this class per se, for a couple of reasons:

1) People already feel the need to be selective in some way about the recipes 
they pull from larger layers such as meta-oe - whether they do it by using 
combo-layer, this class, git-filter-branch or simply by copying the recipes 
they want into their own layers. Using the whitelist class has one advantage 
over all the rest for the simple filtering case - you are always using the 
recipes from upstream. (OK, with combo-layer you probably are, but here it's 
direct.) Besides, even if people aren't doing any active filtering on the 
layer, they almost certainly aren't building the entire thing in any case - so 
can we really say they are testing it now?

2) Responsibility - it's great when people do report issues they find, but we 
shouldn't need to rely on people randomly coming across an issue in order to 
find it, we should be testing it ourselves. The job of maintaining the quality 
of layers rests with us - i.e. the people who are involved in maintaining the 
layers and developing the tools needed to do so. Martin does regular builds 
with a variety of layers as do others. If it's simply parse checking that we 
feel we are losing, it would be trivial to add extra regular checks; if 
nothing else, the layer index is parsing every recipe in almost every public 
layer every three hours; with a little extra work we could log and expose the 
results of that through the interface. (Am I volunteering to do this? Sure, as 
it'll probably be on my own time I can't promise to do it soon, but I will get 
to it if nobody else does first.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre