[oe] Splitting meta-oe?

[Andreas Müller]

On Wed, Feb 28, 2018 at 6:17 PM, Alexander Kanavin
<alexander.kanavin at linux.intel.com> wrote:
> 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.
Isn't there somebody outside willing/capable/having enough time to
move to gnome 3? This would be the best way to end the gnome2 bit-rott
discussion and we'd have a desktop which is commonly used and
addresses touch input. I tried that many years ago but the blocker at
that time was gobject-introspection. These times are over for long. I
wanted to start this during christmas-holiday but then my
music-machine turned into more efforts than expected... For those
still wanting what's left over from gnome2 currently (for me gedit - I
don't like gedit3 search..) there is at least the mate-project an
alternative.
>
> 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.
For example: What if something changes upstream that makes it very
difficult or impossible for us to follow? Have no recent example for
that but I think if gobject-introspection would have worked for us
years ago, gnome2 would not be an issue anymore. You mention below
that in this case a patch has to be sent out. A comment in the recipe
would be good enough?
> 2. Recipes which fail to build, and the situation hasn't been addressed, in,
> say, six months.
Yes: recipes not building are useless. Martin has done blacklisting in
the late phase of his maintainer-ship. The only question I have here:
Does not build mean for all archs or for just .. how many?
>
> 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.
>
I remember the times of mass blacklisting (if I remember correct last
was recipe-specific-sysroot) this was

* kind of alarm for me for those recipes I need / take care of
* easy grep'able for those recipes I thought 'why not - I have some
spare cycles left over'

So my opinion:
* Recipes not building for a time to be defined: 1. blacklist and
after x month -> remove
* Recipes outdated: same 1.blacklist (undo if somebody complains with
patch commenting in the recipe why not to remove) 2. remove after a
time period to be defined

Problem/Challenge:
The way this was handled in the past was an extra duty put on
maintainer's shoulders. If somebody could create (or is there
something already?) a script for that and append it to world builds...

Andreas