[Toaster] More Projects design (YP6232)
Barros Pena, Belen
belen.barros.pena at intel.com
Fri Jul 11 01:54:56 PDT 2014
On 11/07/2014 08:16, "Reyna, David" <david.reyna at windriver.com> wrote:
>I am flexible about this wording - I just wanted to bring this question
>to your attention.
Fair enough. If you can think of something better, do let me know. It can
be tricky to get the labelling right
>
>I am trying to fully understand your words and assumptions. What is your
>"Imported layer source"? Is that an object separate from the user's layer?
My explanation might not be technically accurate, but in my head a layer
source is a collection of information about a set of layers, not the
layers themselves. Because one of the pieces of information in the
collection is the layer repository, once a layer from a collection is
added to a project it can be cloned when you start a build. Now, this git
repository I guess can live anywhere accessible to the build hardware: in
a public server or service (e.g. Github) or in a server inside your
organisation.
So the "Imported" layer source is the collection of information about the
layers imported by users. Like other layer sources, it can be searched and
filtered, and layers from it added to projects.
>When you write "effectively that imports the layer information" are you
>implying a physical copy or just a logical reference?
I think it's a logical reference (i.e. a set of information about the
layer that allows the build system to clone it). Looking at
http://layers.openembedded.org might give you an idea of what I mean.
>
>In the call you mentioned that you expected that the imported layers
>would be in a bare git clone format. While this is true for the
>distribution content, I want to mention again that we expect customers
>will have their custom layers in a normal directory format since they
>would be under active development and not compressed into a repo. We
>need to support both formats.
This opens up all kinds of interesting questions regarding development
workflow. In principle, when Toaster is running in the same machine that
runs the builds, it seems simple to allow people to browse the directory
structure when importing a layer and select a local layer directory. But
this opens up other problems. For example, we will allow people to export
projects to be shared with other people, but if you are using a layer that
only exists locally in your computer, the sharing paradigm breaks.
If we assume that the main use case for Toaster is within an organisation
where several people will work together and be jointly responsible for
distro work, enforcing the use of repositories as a way to share layers
might be a reasonable thing to do. I could be wrong though.
>
>BTW, this brings to mind a related question. Is it the assumption that
>any imported layer must exist both on the host (so that it can be parsed)
>but also at the remote build machine (so that the builder can use it)? If
>not, does this indeed imply a copy action of the layer to that remote
>builder? What is our plan and guidance to the users here?
I believe the layers will just be cloned in the remote build machine as
needed. Alex should be able to confirm this.
Cheers
Belén
More information about the toaster
mailing list