[oe] [OE-core] Quality of meta-oe metadata

[Martin Jansa]

On Sun, Mar 30, 2014 at 03:48:09PM +0100, Paul Barker wrote:
> Are you discussing meta-oe alone here or all layers in meta-openembedded?

basically all of the layers which are included in my world builds, so it
includes all layers in meta-openembedded, most from meta-smartphone,
meta-browser, meta-qt5..

> I've got a few ideas thinking slightly outside the box, so these may
> or may not be workable:
> 
> - It might help to try to split the layers down further and reduce the
> size of meta-oe (for example, create a meta-python layer for all the
> python libraries that aren't direct dependencies of something
> non-python in meta-oe) and then try get new maintainers for these
> sub-layers so that the workload is spread better.

Agreed I would be happy to accept patches creating meta-python layer,
ideally sent by someone who will volunteer to maintain it.

> - We could create a new layer for unstable recipes which are 'use at
> your own risk'. That may be a good place for recipes which don't work
> on the jenkins builds but do work for some people and are in use (and
> so probably don't belong in nonworking). This is similar to the
> meta-broken or meta-nonworking layer idea but would take slightly more
> recipes in.

The difference between meta-broken and meta-unstable from my POV is
that, "broken" should be just temporary place and someone should
eventually fix it, but if we move stuff to meta-unstable and stop
testing it, then I fear that it will became just junkyard.

If some recipe works fine for someone when building for arm, but
triggers "jenkins/world" build issues for x86* then lets restrict it
only for arm with comment which shows the error - that's better than
moving it to "broken" or "unstable".
 
> - It may be worth taking some aggressive action in sync with the
> upcoming oe-core release to get us to a green build, possibly by
> throwing things into meta-nonworking and meta-unstable layers. That
> may break a few people's builds, but the fix for them should just be
> to add the meta-unstable layer. If they're building against the master
> branch that should be tolerable and it won't affect anyone building
> from a released/stable branch until the next oe-core release in 6
> months time. Once we have a green build it'll be much easier to QA
> patches and reject those which break the build.

you mean being aggressive before or after creating the "next-release"
branch? I would prefer to be aggressive before to have green builds in
release branch.

> I don't have much time to give to fixing this myself as I'm busy with
> other projects. I do have idle computer time though so could run an
> automated build regularly (probably just a script and a cron job
> rather than buildbot/jenkins/etc). I won't be able to do a world build
> for every layer for multiple machines, but I should be able to do some
> subset. I may also be able to commandeer a spare server over the next
> few weeks. Is there any particular config which would be beneficial to
> build regularly?

Doing "big" builds in different setups is of course useful, but right
now I think we already have "more logs than what we're processing".

So I think that building not whole world, but those recipes which are
regularly failing would be good start, if people cannot reproduce some
issues which are shown in my jenkins builds we should compare the builds
and narrow possible reasons (e.g. failing only with dash, failing only
with some PACKAGECONFIG enabled or disabled).

I'm trying to stay close to distroless config, but some tweaks are
needed in order to have bigger test coverage (e.g. enabling some
PACKAGECONFIGs which are disabled by default, but something requires
them, or changing P_V to newer again because something else needs it,
enabling gold, because it's more strict so it can catch more issues..)

Jenkins builds are running almost non-stop (because it usually takes
around 24 hours per architecture), so often when I want to debug the
issue directly on that server in WORKDIR where it failed it's already
gone from tmpfs and the workspace is already "blocked" by next build.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20140330/60af7709/attachment-0002.sig>