[Toaster] More Projects design (YP6232)
Damian, Alexandru
alexandru.damian at intel.com
Mon Jul 14 04:31:30 PDT 2014
Alex has some comments below,
On Fri, Jul 11, 2014 at 9:54 AM, Barros Pena, Belen <
belen.barros.pena at intel.com> wrote:
>
>
> 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.
>
I was talking in another thread about "*build repeatability",* which I
think should be one of the basic principles of the build control system for
Toaster - once you export a project and you import it in another Toaster
instance, you will get the same output for the same project settings.
IMHO, my usage model for Toaster is to allow a user to *configure* a build
that then will be shipped to a build farm somewhere, and not as a
fully-fledged IDE since it can't do any edits in the web interface, it only
can do build configuration.
Using local directories, as Belen pointed out, will break the
repeatability principle. I think our options here are:
a). mark an "invalid" state for the project, which will prevent project
exporting
b). do not allow local development directories;
I would favour b). because,
first, it's not clear to me how one would go from marking a project
from "invalid" to "valid", i.e. the offending layers would have to be
deleted and then re-imported, and the project revalidated, offsetting any
work already done; and,
second, if you're doing local hard-core development on your own
layers, probably you will not use the web interface anyway, since it's an
awkward usage paradigm here: you use a terminal to edit local directories,
and then switch to web interface to build something; why would you do that,
when it's easier and faster to just run bitbake from the command line, and
have Toaster running in interactive mode, like in 1.6 release
Does this make sense ?
>
> >
> >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.
>
The specified layers are cloned in the build environment before the
bitbake server starts. There are no code differences between using your
machine to build, or using a hosted infrastructure somewhere else.
In all respects, Toaster treats a remote machine just as a local machine,
and viceversa. I'm beginning to understand that your vision is to use
Toaster to do local layer development, but I think that we're not ready to
tackle this aspect. I think that Toaster builder functionality should focus
on configuring builds on already validated layers, and have our users use
the Toaster running in 1.6 mode (interactive) to debug builds while
creating own layers.
To use Toaster as an
IDE, we would need the ability to edit recipe sources, view detailed
logs, and run advanced bitbake commands directly in the web interface, and
I think this is well beyond 1.7
> Cheers
>
> Belén
>
>
--
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20140714/ee6fccc3/attachment.html>
More information about the toaster
mailing list