[oe] Splitting meta-oe?

[Joe MacDonald]

[[oe] Splitting meta-oe?] On 18.02.20 (Tue 10:45) Burton, Ross wrote:

> Hi,
> 
> Is now a good time to talk about splitting up meta-oe?  Some layers are
> actively developed and maintained (one example: meta-python), others are
> basically bitrotting and only get touched when something else causes them
> to break world builds (one example: meta-gnome).  I've long felt that
> meta-oe should be split up and the high quality layers managed in their own
> repositories so patches to them don't get held up by breakage in other
> sub-layers.

Way back when I first proposed creating meta-networking I pitched it as
a separate layer managed outside the meta-oe umbrella.  At the time I
thought it made sense for my use case and for the use case I anticipated
from consumers of meta-networking packages both for the reasons you
state below and because my intent was to create a layer primarily useful
for creating network-centric devices (bridges, firewalls, switches, APs,
etc.) with an absolute minimum of other layer dependencies.  I think I
actually proposed the highly ambitious goal of oe-core + meta-networking
as a functional set.

Anyway, in the intervening time there's been enough situations crop up
that now the minimal set is something like oe-core + meta-oe +
meta-perl(we're still open on that, I think) + meta-python +
meta-networking.

So my original goal of keeping meta-networking largely independent of
other layers isn't practical (wasn't from get-go, really) and I'm okay
with that.  I also think there's considerable value in being able to say
"we don't need that recipe in this layer, it's already maintained by
someone else in a common area in the same repo, just a different layer".
I wouldn't want to start down a path that leads to multiple incompatible
versions of recipes being maintained in layers purely out of convenience
to the layer maintainer.

I can see a lot of value in removing old recipes / layers that aren't
being used and / or have fallen far out of date, though.  If you've got
a list of those you'd like to discuss, I'm sure that's a useful
discussion to have.

I'll also take the opportunity to plug my old patch for flagging recipes
as deprecated (https://patchwork.openembedded.org/series/5489/).  It's
never gotten any traction, but I think it's a good early-warning for
consumers of recipes that are quietly using them with reasonable success
as-is despite any issues the maintainers may have with them.  Could be a
good way to determine who actually cares about these problem child
recipes before they become a big enough headache that we just need to
abandon them.

-J.

> Another advantage of splitting out the high quality layers is that we'd
> like to look at running more community layers through the Yocto
> autobuilder, and granular layers make that easier to manage.
> 
> Comments?
> 
> Ross
-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20180220/2b8285f4/attachment-0002.sig>