* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-21 10:45 ` Richard Purdie
@ 2015-08-21 10:52 ` Otavio Salvador
2015-08-21 11:59 ` Patrick Ohly
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Otavio Salvador @ 2015-08-21 10:52 UTC (permalink / raw)
To: Richard Purdie
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
On Fri, Aug 21, 2015 at 7:45 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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'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...
I fully support your objection and I also nervous about this one.
Often vendors want to narrow their responsibility and focus so this
class opens the door for this to be done officially. :-(
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-21 10:45 ` Richard Purdie
2015-08-21 10:52 ` Otavio Salvador
@ 2015-08-21 11:59 ` Patrick Ohly
2015-08-21 17:45 ` Khem Raj
2015-08-24 11:02 ` Paul Eggleton
3 siblings, 0 replies; 14+ messages in thread
From: Patrick Ohly @ 2015-08-21 11:59 UTC (permalink / raw)
To: Richard Purdie; +Cc: Paul Eggleton, openembedded-core
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-21 10:45 ` Richard Purdie
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-24 11:02 ` Paul Eggleton
3 siblings, 1 reply; 14+ messages in thread
From: Khem Raj @ 2015-08-21 17:45 UTC (permalink / raw)
To: Richard Purdie
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
On Fri, Aug 21, 2015 at 3:45 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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'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...
All points here are valid. We already see this with distro's which use
layers verbatim e.g. angstrom
I wish everyone derived their distros that way since that respects the
layer boundaries, a good chunk of work
there is still we send patches to layers to keep them up to date with
changes in other layers and there still are patches
pending since every layer maintainer doesnt respond in sam time frame,
but this sort of facilities if added is just going to worsen that
workload.
I think amalgmation of layers start with use of combo-tool itself.
This patch just takes it a step further. If we want to preserve
the layer model's health we have to work towards respecting layer
boundaries and I would even go a step further and suggest to
discourage use of combo-tool or any sort of layer squashing.
>
> Cheers,
>
> Richard
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-21 17:45 ` Khem Raj
@ 2015-08-21 21:43 ` Otavio Salvador
2015-08-21 22:41 ` Richard Purdie
0 siblings, 1 reply; 14+ messages in thread
From: Otavio Salvador @ 2015-08-21 21:43 UTC (permalink / raw)
To: Khem Raj; +Cc: Paul Eggleton, Patches and discussions about the oe-core layer
On Fri, Aug 21, 2015 at 2:45 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Aug 21, 2015 at 3:45 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> 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'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...
>
> All points here are valid. We already see this with distro's which use
> layers verbatim e.g. angstrom
> I wish everyone derived their distros that way since that respects the
> layer boundaries, a good chunk of work
> there is still we send patches to layers to keep them up to date with
> changes in other layers and there still are patches
> pending since every layer maintainer doesnt respond in sam time frame,
> but this sort of facilities if added is just going to worsen that
> workload.
> I think amalgmation of layers start with use of combo-tool itself.
> This patch just takes it a step further. If we want to preserve
> the layer model's health we have to work towards respecting layer
> boundaries and I would even go a step further and suggest to
> discourage use of combo-tool or any sort of layer squashing.
I fully agree; in fact Poky itself is a bad example that I often have
to explain for vendors. People justify putting several layers together
in same repository saying that Poky does that and this is a
contradiction which we need to justify as Yocto Project promotes the
use of layers as one of most preeminent features but Poky does the
opposite ...
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-21 21:43 ` Otavio Salvador
@ 2015-08-21 22:41 ` Richard Purdie
0 siblings, 0 replies; 14+ messages in thread
From: Richard Purdie @ 2015-08-21 22:41 UTC (permalink / raw)
To: Otavio Salvador
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
On Fri, 2015-08-21 at 18:43 -0300, Otavio Salvador wrote:
> On Fri, Aug 21, 2015 at 2:45 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > All points here are valid. We already see this with distro's which use
> > layers verbatim e.g. angstrom
> > I wish everyone derived their distros that way since that respects the
> > layer boundaries, a good chunk of work
> > there is still we send patches to layers to keep them up to date with
> > changes in other layers and there still are patches
> > pending since every layer maintainer doesnt respond in sam time frame,
> > but this sort of facilities if added is just going to worsen that
> > workload.
> > I think amalgmation of layers start with use of combo-tool itself.
> > This patch just takes it a step further. If we want to preserve
> > the layer model's health we have to work towards respecting layer
> > boundaries and I would even go a step further and suggest to
> > discourage use of combo-tool or any sort of layer squashing.
>
> I fully agree; in fact Poky itself is a bad example that I often have
> to explain for vendors. People justify putting several layers together
> in same repository saying that Poky does that and this is a
> contradiction which we need to justify as Yocto Project promotes the
> use of layers as one of most preeminent features but Poky does the
> opposite ...
Another way of looking at the issues people are having is that
meta-openembedded is simply too large and it really needs to get split
up into separate repos so people can get more granularity.
That is both technically hard in some ways and controversial and nobody
wants to step up and try and form a consensus about doing it though. I
would note the internal splits are a good start though and there is some
separation of maintainership happened there already.
On the subject of poky, right from the start poky was a subset of
OpenEmbedded, for good reason if we remember OE from those days. That
reason was originally that OpenedHand didn't want to support all of OE
for a customer, only some subset. The OSVs using the Yocto Project still
have this issue today. The big difference between combo-layer and the
whitelist is that in one case you don't ship the recipe. This makes it
really clear to the customer what is and what is not supported. This has
pros and cons, obviously.
I will state for the record that poky only has complete layers in it
though, it doesn't pick components of meta-oe, I've actively avoided it.
Putting layers together in one accessible form is a different topic in
some ways to filtering one layer into a sublayer.
Patrick commented that whitelist and combo-layer both have the same
drawback to metadata quality and that is probably true, I wasn't trying
to suggest otherwise, merely highlight the other options available and
their relative merits (which I didn't do a good job of).
Cheers,
Richard
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-21 10:45 ` Richard Purdie
` (2 preceding siblings ...)
2015-08-21 17:45 ` Khem Raj
@ 2015-08-24 11:02 ` Paul Eggleton
2015-08-25 16:20 ` Randy MacLeod
3 siblings, 1 reply; 14+ messages in thread
From: Paul Eggleton @ 2015-08-24 11:02 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
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@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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-24 11:02 ` Paul Eggleton
@ 2015-08-25 16:20 ` Randy MacLeod
2015-08-25 16:32 ` Paul Eggleton
0 siblings, 1 reply; 14+ messages in thread
From: Randy MacLeod @ 2015-08-25 16:20 UTC (permalink / raw)
To: openembedded-core, Paul Eggleton
On 2015-08-24 07:02 AM, Paul Eggleton wrote:
> 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@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.)
Makes sense to me. I don't see the whitelist.bbclass in master-next yet.
Are you just waiting for the linux-4.1 and gcc-5.2 to go in?
../Randy
>
> Cheers,
> Paul
>
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
Canada, K2K 2W5
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
2015-08-25 16:20 ` Randy MacLeod
@ 2015-08-25 16:32 ` Paul Eggleton
0 siblings, 0 replies; 14+ messages in thread
From: Paul Eggleton @ 2015-08-25 16:32 UTC (permalink / raw)
To: openembedded-core
On Tuesday 25 August 2015 12:20:40 Randy MacLeod wrote:
> On 2015-08-24 07:02 AM, Paul Eggleton wrote:
> > 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@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.)
>
> Makes sense to me. I don't see the whitelist.bbclass in master-next yet.
> Are you just waiting for the linux-4.1 and gcc-5.2 to go in?
Patrick was asking me to address his remaining issue, so at minimum we're
waiting for me to do that I believe.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 14+ messages in thread