[oe] Splitting meta-oe?

[Alexander Kanavin]

On 02/20/2018 12:45 PM, Burton, Ross wrote:
> 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.
> 
> 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?

I just read the whole discussion (been on holiday), and while it seems 
that splitting layers is seen as too heavy-handed, there is still 
something that I believe should be done: a policy for blacklisting and 
removing unmaintained recipes. Such a policy should be:

a) clearly defined;
b) consistently applied.

If that is in place, I, as an oe-core maintainer, would be a lot more 
willing to contribute to meta-oe, knowing that recipes I contribute to 
(for example by fixing issues caused by changes in oe-core) are, in 
fact, used and taken care of otherwise. However, me endlessly fixing 
well obsolete gnome2 stuff is just a fast track to not caring anymore.

So, which recipes are unmaintained?

1. Badly out of date compared to upstream development. Say, one year or 
more between version provided by meta-oe master, and latest version 
released by upstream.
2. Recipes which fail to build, and the situation hasn't been addressed, 
in, say, six months.

Once either of these is established, the recipe enters a grace period 
before it is removed. Any objection to such removal should come with a 
patch that addresses the reason for it.


Alex