[oe] Splitting meta-oe?

[Martin Jansa]

I still fail to see how splitting the layers into separate repositories
will magically help with the quality of recipes stored there.

meta-python, meta-perl, meta-filesystems, meta-gnome, meta-networking,
meta-webserver, meta-xfce all depend on meta-oe layer.

Build testing fewer layers in "world" builds will probably lower the
overall quality of the layers (and their compatibility with each other).

Building the same set of layers in "world" builds just from different
repositories, won't make the build failures go away, it will just cause
more work for Armin or whoever will be willing to continue running those
builds.

Testing some layers like meta-python and meta-perl on YP auto builder would
be nice, but why do they need to be in separate repository for that?

Making meta-networking, meta-python and meta-perl not to depend on meta-oe
is also nice goal, but again not blocked by all these layers sharing the
same git repository. Creating new
meta-shared-stuff-nobody-knows-how-to-call-this-layer as common dependency
for these 3 is also possible in meta-oe git repository (even easier to
switch to then creating new repository for each of them).

Armin is still merging patches e.g. to meta-python even when last clean
"bitbake world" status was on 2017-05-03. So don't make it sound like
meta-gnome is blocking meta-python progress. FWIW: There is only one
failing recipe in meta-gnome and at least 7 failing in meta-networking (to
be fair 5 of them are caused by very recent kernel upgrade).

If the git repository has the reputation (not the layers you're using from
there), then I can say that oe-core git repository is quite bad, because it
has meta-skeleton which doesn't have anything useful for me and has only 4
commits in last 2 years.

Regards,

On Tue, Feb 20, 2018 at 7:00 PM, Tim Orling <ticotimo at gmail.com> wrote:

> The recent improvements to the Auto Upgrade Helper have made maintenance of
> meta-perl less effort and therefore you have seen an uptick in my updates
> to recipes. I also plan to mass-add ptest to all perl module recipes
> "sometime soon", which will further simplify my upgrade workflow and add to
> the confidence of said recipes. My upgrade workflow touches all recipes in
> oe-core, meta-oe and meta-perl that fit a lib*perl regex.
>
> I will note, however, that we are revisiting meta-cpan and that may
> ultimately be the preferred perl layer. If you really heavily on perl
> modules, please comment on whether meta-cpan would fit your needs.
>
> Derek and others have been doing a great job keeping meta-python up to
> date. I mostly jump in when there are trickier failures that need more
> concentrated effort. I would like to see increased testing (more packages
> with ptest), but that is trickier with python recipes as there are many
> more approaches to testing than there are in perl. I am happy with the
> current efforts to keep recipes up to date as a priority. I would like to
> see complete coverage of python3 for all recipes that are capable in
> meta-python.
>
> I am open to discussion about what direction we go. Individual layers that
> are curated and built together by YP auto builders sounds like an
> intriguing path. If this was coupled with increased ptest or testimage
> usage, our confidence in layer quality would go up dramatically.
>
> Cheers,
>
> --Tim
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>