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
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
