Re: [OE-core] [RFC PATCH] bitbake-layers: add layer repositories/revisions save and restore tooling (aka 'layer configuration')

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2022-07-05 at 10:39 +0200, Alexander Kanavin wrote:
> On Tue, 5 Jul 2022 at 10:34, Alexander Kanavin via
> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
> wrote:
> > At this point, I have to remind everyone about our harsh reality.
> > Which is having lots of core pieces without maintainers:
> > https://git.yoctoproject.org/poky/tree/MAINTAINERS.md#n45
> > 
> > Let's focus on adding foundational pieces of layer and configuration
> > management in a controlled, testable and tested manner for now. Which
> > is what I am trying to do. I think discussing grandiose designs for
> > things that try to please everybody is just a bit premature, honestly.
> 
> And let me just go ahead and say it, and I understand this may be
> upsetting. I'd rather try really hard to completely avoid the
> standalone setup tool.

I've been trying that for years, it is looking like it is no longer an
option as if we don't do something, I think the project will suffer
more damage than a tool would do.

>  That tool, and the way it's just been described
> sounds like an invitation to compatibility issues between various tool
> versions and the metadata and backends (kas alone has more than 12
> config format versions and requires to specify the version
> explicitly?) coming from all kinds of places, maintainability issues
> (we are already pressed to the limit with many pieces getting no
> maintenance), leaky abstractions, not quite covering all of the ways
> people want to use it with their existing setups, and overall greatly
> increased complexity in a project that is already notorious for it.

In defence of the tool idea, we do have some experience of what
compatibility looks like through the autobuilder. There are a lot of
parallels in what it does and how it does it to what we need in that
standalone tool. Yes, there are differences needed but there is a
decent chunk of experience which can be used to hopefully largely avoid
those compatibility issues.

> I'd rather avoid repeating the story with devtool, which is both more
> complex and has less use than what we'd hope for - and has no
> maintainer.

I don't think the setup tool should impact devtool, those are two
different components which should be orthogonal to each other. Yes,
there is impact on the eSDK but I'd hope in general that would be a
simplification of the existing setup code.

Cheers,

Richard