Hi Belén,

Thank you, I have learned a lot from your reply! Here are my immediate 
reactions.

> If you have a collection of commercial layers that you would like Toaster
> users to get access to, you would specify them as a layer source in the
> toasterconf.json file, so yes, those commercial layers would be part of a
> "preconfigured" layer source

Ok, I understand. 

The only question remaining is if such edits for this file (and other config 
files) are under GPL or not. I myself do not know.

> The data is shared: it goes to the database so it cascades across all
> projects using the edited layer.

Ok.

> What Toaster does try to do is making that meta-data easily accessible. I
> no longer need to go hunting around GitHub or the OE Layer Index to see if
> a layer exists that provides xyz recipe: I can find that out within
> Toaster

That is explains the question. It is the state of the layers in the wild that 
you are addressing here.


> >Or do the error messages on page 7 imply an actual clone action?
> 
> They imply a failed clone action in the build server:

Ah, that explains it. I was surprised to see it here in the context of the 
Layers pages and not part of some "build" document.

> No, it doesn't: the layer is added to the Imported layer source, and it
> will become part of the all layers list. You could add it to a different
> project using the same release, as explained above.

Ok.

- David

> -----Original Message-----
> From: Barros Pena, Belen [mailto:[email protected]]
> Sent: Wednesday, September 03, 2014 5:59 AM
> To: Reyna, David; [email protected]
> Cc: DAMIAN, ALEXANDRU; Wymore, Farrell
> Subject: Re: Design - layer details page
> 
> Hi David,
> 
> Thanks for the review. Long answers to your questions inline. I hope they
> help!
> 
> Cheers
> 
> Belén
> 
> On 03/09/2014 10:52, "Reyna, David" <[email protected]> wrote:
> 
> >Hi Belen,
> >
> >I have read your excellent document, and had a few questions. I guess
> >that I am trying to reverse engineer the design from the pages, and the
> >pages to not directly describe that design.
> >
> >
> >1) I am trying to understand "editable" versus "non-editable" layers.
> >
> >What is a "preconfigured layer source"? Is this one that is part of the
> >YP distribution, where everything else is an "imported layer", and thus
> >is editable?
> >
> >   1. Not editable: the detail pages for layers from preconfigured
> >   layer sources (e.g. OpenEmbedded layer source)
> >   2. Editable: the detail pages for imported layers, where
> >   the information in the "Layer details" tab and in the
> >   "About" section can be edited by Toaster users.
> >
> >In part my question is about commercial layers, if they could be
> >identified through some mechanism as "preconfigured"?
> 
> A "preconfigured" layer source is a layer source specified in the
> toasterconf.json file. That file allows Toaster administrators to
> determine which layer sources will be available to the users of the
> Toaster instance. By default, we ship Toaster with the OpenEmbedded layer
> source, which means users will see the layers available at
> http://layers.openembedded.org
> 
> If you have a collection of commercial layers that you would like Toaster
> users to get access to, you would specify them as a layer source in the
> toasterconf.json file, so yes, those commercial layers would be part of a
> "preconfigured" layer source, and the information about them will be
> presented in the not editable version of the layer details page.
> 
> The editable page is used to present information about those layers which
> users "import" manually into Toaster by completing the "Import layer"
> form.
> 
> >
> >2) What is the life cycle of the edited data of a layer (page 11)?
> >
> >Does it only live in a local clone of the layer?
> 
> There is no local clone of the layer, unless you are running Toaster in
> the same computer that runs your builds. When you import a layer, you are
> adding to the database the information needed to clone that layer in the
> build server. I hope I am explaining this right: Alex / Paul, please
> correct me otherwise.
> 
> 
> >If another project uses the same layer, would that edited data be shared
> >or would it have to entered again?
> 
> The data is shared: it goes to the database so it cascades across all
> projects using the edited layer.
> 
> >
> >Or is the information pushed up to the imported layer source?
> 
> The information is "pushed" to the imported layer source, which is used by
> all projects: that is how it "cascades" across projects.
> 
> To understand this fully I guess we need to talk about the concept of
> "project release". The toasterconf.json file not only allows you to
> specify layer sources, but also a list of valid releases users can select
> when creating a project. I'll use the Yocto Project as an example, but you
> could specify vendor releases as well. By default, Toaster will come with
> 2 releases: Yocto Project 1.6 and Yocto Project 1.7. So when users create
> a project, they can decide if they want to use Yocto Project 1.6 to run
> their builds, or Yocto Project 1.7.
> 
> When you import a layer, the layer must be compatible with the release
> selected for the project within which you are importing it. So I create
> project "Test" and I select 1.6 as the release. I have my own layer
> meta-me that I want to use in this project, so in the "Test" project page
> I select the "Import layer" option and enter the layer details. When you
> import the layer it is marked as compatible with 1.6, which is the release
> of the "Test" project. The imported layer "meta-me 1.6" will then be
> available for me in the All layers page of any other projects that also
> use the 1.6 release. So if after importing meta-me 1.6 I create a project
> "Test2" that also uses the 1.6 release, I will be able to go to the all
> layers page in Test2, search for meta-me and add it to the project.
> "meta-me 1.6" will not be available in projects using the 1.7 release,
> though. If I have a second version of meta-me that is compatible with 1.7,
> I will need to import it within the context of a project using the 1.7
> release.
> 
> This is a very long explanation, but the basic rules are 2:
> 
> 1. The all layers list, which includes layers from preconfigured layer
> sources and layers imported manually, is global, but exposed only in the
> context of a project
> 
> 2. The all layers list shows you only layers compatible with the release
> of the selected project
> 
> Those 2 rules aim to keep things simple (they are a starting point), and
> create some basic safeguards for meta-data compatibility (in a project
> where you have selected the 1.6 release, we don't give you the chance to
> choose 1.7 layers, which probably will not build with 1.6).
> 
> 
> >
> >3) I guess I am in general curious why Toaster is in the business of
> >creating meta-data for layers?
> >
> >Does this reflect the general state of layers that we expect to import,
> >that they are incomplete? Or are we working towards a layer management
> >and/or creation tool?
> 
> I am not sure I fully understand this question. I don't think Toaster is
> "in the business of creating meta-data": layers are meta-data. Toaster
> just "uses" that meta-data. In order to do so, it needs some basic
> information about it: the layer name, a git repo and the commit you want
> to use.
> 
> What Toaster does try to do is making that meta-data easily accessible. I
> no longer need to go hunting around GitHub or the OE Layer Index to see if
> a layer exists that provides xyz recipe: I can find that out within
> Toaster and add that layer to my configuration with a single click. And if
> I have my own layer that I use all the time, I can import it once and then
> use it across different projects.
> 
> >
> >4) You have a button titled "Delete the meta-imported layer from your
> >project".
> >
> >I am wondering if "Remove..." is a better phrasing since (a) it matches
> >with "Add...", and (b) the word "delete" sounds like something is being
> >erased from the disk instead of just being taken out of the project's
> >layer list.
> 
> We can definitely replace "delete" with "remove". However, we need to bear
> in mind that those "remove" buttons and icons are used across the
> interface for other things (an example would be optional layer
> information, such as "Summary", "Description" or "Repository
> subdirectory"). For those things, "delete" might make more sense than
> "remove". Whichever word we pick, however, we should use across the whole
> interface: I wouldn't like to see "delete" in some places and "remove" in
> others when everything else (icon, interaction, etc) is exactly the same.
> 
> >Unless there was an actual copy happening during the "Add..." action?
> 
> No, I don't think that's the case. The "Add" action simply adds some
> information to the project configuration that will be used for the build.
> 
> >I understand that the remote build will dynamically clone any included
> >layers, but those are transient anyway right?
> 
> I think this is correct.
> 
> >Or do the error messages on page 7 imply an actual clone action?
> 
> They imply a failed clone action in the build server: build server tries
> to clone the layer using the information Toaster provided, the cloning
> fails, build server "reports back" to Toaster that the layer failed to
> clone.
> 
> >
> >5) I am still trying to understand the layer "Just import for the moment"
> >option.
> >
> >What happens when you click the "Just import for the moment" button, you
> >are taken to the layer details page (with a notification at the top
> >telling you that you have successfully imported the layer), and you do
> >_not_ use the "add it to your project" link? Does the layer then
> >disappear when you leave this page?
> 
> No, it doesn't: the layer is added to the Imported layer source, and it
> will become part of the all layers list. You could add it to a different
> project using the same release, as explained above.
> 
> >
> >- David
> >
> >> -----Original Message-----
> >> From: Barros Pena, Belen [mailto:[email protected]]
> >> Sent: Tuesday, September 02, 2014 8:24 AM
> >> To: [email protected]
> >> Cc: DAMIAN, ALEXANDRU; Reyna, David; Wymore, Farrell
> >> Subject: Design - layer details page
> >>
> >> Finally managed to finish this piece. Sorry for the delay: there is
> >>quite
> >> a bit going on in this page. Design document attached to the Bugzilla
> >> feature:
> >>
> >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6591
> >>
> >> Any questions, let me know.
> >>
> >> Belén
> >>
> >
> 

-- 
_______________________________________________
toaster mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/toaster

Reply via email to