[Openembedded-architecture] Notes from the OEDAM "Naming Table"

[Trevor Woerner]

Hi Richard,

I'll avoid quoting your email to pick here and there at each line since I
was _very_ happy to read your reply and agree with pretty much everything you
said!

It feels to me like there's a lot of agreement on what's being discussed. As
stupid as this might sound, in order to change anything this big the first
step is to agree there's something worth changing. Not only does it sound like
we agree, it looks like there's agreement on what could be changed :-)

I think we need a way to describe a build that includes:
- all the repositories used
- the locations from which each of the repositories used were cloned
- the head commits of each of the repositories that are used
- a full non-site-specific (i.e. *not* DL_DIR) list of all configuration
  parameters

Ideally this description would be contained in one file.

When a build completes it generates this file (for future
debugging/reference).

This file could be used as the input to a new build, thus recreating someone
else's build somewhere else in an automated manner.

This file could be the basis of what gets uploaded to the layer index. The
purpose of this upload is so that people around the world could perform builds
and upload their results to the layer index to help with the layer quality
metrics. This helps alleviate the requirement for a small number of companies
to run and maintain monster build machines (you could continue with your
current infrastructure for the poky repository, but for layers outside of what
the poky repository provides...). Also, it wouldn't matter of people used
Jenkins, the Yocto buildbots, or whatever else. The build (as part of
buildhistory perhaps?) would generate this file, all you'd need to do is
enable the feature and you'd get the file. You could then upload this file
(with results) manually or perhaps in an explicitly-opted-in configuration
option. Also, this way it doesn't matter if the person who originally
performed this build used repo, submodules, or whatever... the build would
just grab the repositories for itself any which way it wanted (of course we'd
have to be on the lookout for the use of private/local repositories that
aren't available publicly on the Internet).

Best regards,
	Trevor