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