[Openembedded-architecture] bblayers.conf - Past, Present and Future?

[Martin Jansa]

On Wed, May 11, 2016 at 12:42:27PM +0100, Richard Purdie wrote:
> We currently have a few different ways people setup and build
> combinations of OE layers. Koen's presentation and ELC covers some of
> this, we've also heard representations at OEDEM/OEDAM and I think
> everyone would agree that its worth seeing if there is some way we
> could improve the situation.
> 
> We have various tools/options:
> 
> * TEMPLATECONF
> * combo-layer
> * repo
> * git submodules
> 
> and we all have views, some of them quite strong about different
> elements of these.
> 
> At the end of the day, our users want/need something which sets up the
> system for them to use and "works", they don't really care about the
> details. 
> 
> To summarise the general problem, we need some way of saying "get this
> set of git repositories and check them out in this layout, then setup a
> bblayers.conf file like this".
> 
> In parallel, we're seeing people trying to use OE in CI systems. To
> make buildbot work for the Yocto Project, we have a ton of
> configuration and "fetching" code and I know Jenkins integration runs
> into the same issues. We'd love to be able to throw away the need to
> have CI specific layer addition code, or the bulk of the custom git
> fetcher we ended up having to add there for example.
> 
> The key question is perhaps "how this should work?" and then we could
> work backwards from there.

I can imagine set of smaller extensible tools like:
1) fetching defined repos in defined versions
2) generating config files based on some templates
3) triggering some defined combinations for builds as MACHINE x TARGETS

But seeing our infrastructure for CI I cannot imagine one tool which
will suit the needs and expectations of majority of the users.
But we might want to reuse some smaller parts of it which will fit into
our work-flow or be easily adapted to our needs.

On the other hand even the "small" fetcher would need to support many
things, most our builds are triggered from gerrit plugin in jenkins, if
the config file for "layer-fetcher" doesn't know how to checkout gerrit
refspecs from its config file (which may be generated by some other
script which knows how to read gerrit params passed to jenkins job),
then I will continue to use our own solution, people used to repo,
stash, reviewboard, github PRs will have similar problem.

So I'm all for some good examples and small tools which may be
useful, but I wouldn't promote is as the best solution for this whole
problem.

-- 
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: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20160511/80f2012c/attachment-0002.sig>