[RFC] Image customisation detailed design

[RFC] Image customisation detailed design

[Barros Pena, Belen]

As I mentioned in the Toaster weekly meeting last Wednesday, I've recorded
a (not so short, sorry) video showing a much more detailed design for the
image customisation feature. The video is here

https://wiki.yoctoproject.org/wiki/images/a/a1/Image-customisation.webm

Everything that I show in the video is now available in the design
prototype at

https://yoctoproject.org/toaster


Just in case you want to follow along ;)

I think the design addresses pretty much all the feedback the Toaster
contributors have provided so far (listed below). The only items not
addressed are 1 (because it would require us to rethink Toaster as a tool
for absolute beginners and would impose a very specific workflow) and 8
(because I haven't had time to think about how we can do this, but we can
definitely come back to it).

Please send any comments and new feedback to the mailing list so that
Tiago can collect it and we can address it.

This is the feedback we have received so far:

1. Should this kind of linear process be the main Toaster workflow,
instead of the non-linear one currently provided by the existing project
page?

2. Size is project configuration dependent, so all size information is a
guess, an approximation. We should probably still show it, but the
interface needs to present it as such (we need to make sure we don't
present it as it was 100% accurate information). The same for dependencies.

3. We need to create states for how the tables will look like when certain
information is missing (number of packages, sizes, etc)

4. We need to refine the recipe presentation in the workflow

5. We need to work on the way we present the actions. Do we really need
all the ones we have right now?

6. Replace the builds tab with a less prominent way of accessing build
information for the custom image recipe.

7. Provide a way to reenter the image customisation process from the build
results

8. Provide a way to 'select all' packages returned by a search

9. Do we need the reverse dependencies information in the packages table?

10. Can we add the package size to the visible dependencies information in
the packages table?

11. The workflow is still too complex: too many concepts exposed
(packages, layers, recipes). Should we just require people to build the
image they want to customise instead?

Cheers

Belén

Re: [RFC] Image customisation detailed design

[Michael Wood]

[-- Attachment #1: Type: text/plain, Size: 4547 bytes --]

Thanks for the video Belén, Looks good.

Couple of bits of feedback

Creating an image recipe:

I find the text in the modal too long, anything more than 2 sentences 
and my attention span is over!

I found it confusing that I entered a name and clicked create but have 
not actually created anything, what about something like suggestion1.png 
(attached) this brings it more into line with import layer/create new 
project/form based activity.

Select a base image recipe:

I was looking for a way to "de/re/select" an image, we don't quite have 
the same concept here as the machines selection that I was expecting, 
where you can always select regardless of whether it's already selected.

Add and delete packages:

'.well' 1

I was expecting the pencil to do the same as other pencils and activate 
text input boxes. Obviously if you're on the Add/Delete packages page 
you can't change the base image like that so maybe not having these 
pencils would be better. I was also unsure as what the change 
version/licence would do.

'.well' 2

If you've selected an image recipe and then remove the layer that 
provides it... what happens?

The Build Image recipe/ Download recipe file / Delete image recipe 
buttons are somewhat easy to miss, they look a bit like progress buttons 
or other tabs. I wonder if they would be better off in '.well' 1. The 
Build button could be more noticeable.

In general if you can avoid having data in a table that for each one 
requires extra data looking up the tables will be much faster/efficient. 
For example we have the dependencies button with total size displayed. 
It should be really quick to count the number of dependences, but much 
slower if we also have to retrieve the objects to get the data in them, 
such as "name" and "size".  If we can do that by making it "on demand" 
that's much better, e.g. you click the button and it fetches this extra 
data.

Thanks,

Michael



On 12/06/15 14:40, Barros Pena, Belen wrote:
> As I mentioned in the Toaster weekly meeting last Wednesday, I've recorded
> a (not so short, sorry) video showing a much more detailed design for the
> image customisation feature. The video is here
>
> https://wiki.yoctoproject.org/wiki/images/a/a1/Image-customisation.webm
>
> Everything that I show in the video is now available in the design
> prototype at
>
> https://yoctoproject.org/toaster
>
>
> Just in case you want to follow along ;)
>
> I think the design addresses pretty much all the feedback the Toaster
> contributors have provided so far (listed below). The only items not
> addressed are 1 (because it would require us to rethink Toaster as a tool
> for absolute beginners and would impose a very specific workflow) and 8
> (because I haven't had time to think about how we can do this, but we can
> definitely come back to it).
>
> Please send any comments and new feedback to the mailing list so that
> Tiago can collect it and we can address it.
>
> This is the feedback we have received so far:
>
> 1. Should this kind of linear process be the main Toaster workflow,
> instead of the non-linear one currently provided by the existing project
> page?
>
> 2. Size is project configuration dependent, so all size information is a
> guess, an approximation. We should probably still show it, but the
> interface needs to present it as such (we need to make sure we don't
> present it as it was 100% accurate information). The same for dependencies.
>
> 3. We need to create states for how the tables will look like when certain
> information is missing (number of packages, sizes, etc)
>
> 4. We need to refine the recipe presentation in the workflow
>
> 5. We need to work on the way we present the actions. Do we really need
> all the ones we have right now?
>
> 6. Replace the builds tab with a less prominent way of accessing build
> information for the custom image recipe.
>
> 7. Provide a way to reenter the image customisation process from the build
> results
>
> 8. Provide a way to 'select all' packages returned by a search
>
> 9. Do we need the reverse dependencies information in the packages table?
>
> 10. Can we add the package size to the visible dependencies information in
> the packages table?
>
> 11. The workflow is still too complex: too many concepts exposed
> (packages, layers, recipes). Should we just require people to build the
> image they want to customise instead?
>
> Cheers
>
> Belén
>
>
>
>
>


[-- Attachment #2: suggestions1.png --]
[-- Type: image/png, Size: 146632 bytes --]

Re: [RFC] Image customisation detailed design

[Reyna, David]

Hi Belén,

I also appreciate the video and sample Toaster pages!

Here are my comments, in addition to Michael's.

1) Can we add a filter so that we can show just the packages that we can delete? 

The use case is trimming the image, where we want the 100 packages that we wish to examine for removal not to be lost in the possible 1000's packages that are available to add.

2) I will admit that I was thrown by the new status pop-up, because not only does it cover things up on my page, I also generally associate them with spam and ad-ware.

I understand your use for showing an action in progress, but we already had a metaphor for that in the progress/status bars inserted (when applicable) at the top of the page. Why a new metaphor? What does it add that the regular model does not? I know that it does stay visible while you for example scroll, but is that a hard requirement?

I also do not understand the dangling part, where I have to manual cancel it to make it go away. For example, I understand for example its use in the add layer parsing progress, but when it is done and says "Layer Information updated" why do I have to manually kill it? Could it at least go away on its own after a moment, and let that be the clue that the process completed?

The "Undo" feature though is nice!

3) The new page can add layers in place which is nice, and I see how you can use it to parse and show that layer's package count. However, it appears that if I change my mind about the layer I have to go out to the layer page to remove it? Could perhaps the "undo" feature also be made available here? Or a layer delete icon?

Speaking of layer parsing, don't we already have an idea of the package count per layer from the "all packages" table? 

4) How does this interface deal with "package groups"? People will ask.

http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks


5) Concerns about package removal

Adding packages is easy, but we (WR) have found that removing them is weirdly hard. I am very curious how the backend package removal/exclusion is being done, and who is doing it. In any case, we should have disclaimers in place.

  * Some removed packages appear anyway in the image, because sometimes the dependency information in the packages are not complete nor correct.

  * Some removed packages will break the build or the runtime, even though the dependencies say it should be ok. Users should be encouraged to test their changes early and often, and we may want to help save their bacon with checkpoints (based on the last successful build?) or multiple undo's so that they can back up to a working state rather than re-starting from scratch. Just saying.

- David


> -----Original Message-----
> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> bounces@yoctoproject.org] On Behalf Of Michael Wood
> Sent: Tuesday, June 23, 2015 9:32 AM
> To: toaster@yoctoproject.org
> Subject: Re: [Toaster] [RFC] Image customisation detailed design
> 
> Thanks for the video Belén, Looks good.
> 
> Couple of bits of feedback
> 
> Creating an image recipe:
> 
> I find the text in the modal too long, anything more than 2 sentences
> and my attention span is over!
> 
> I found it confusing that I entered a name and clicked create but have
> not actually created anything, what about something like
> suggestion1.png
> (attached) this brings it more into line with import layer/create new
> project/form based activity.
> 
> Select a base image recipe:
> 
> I was looking for a way to "de/re/select" an image, we don't quite have
> the same concept here as the machines selection that I was expecting,
> where you can always select regardless of whether it's already
> selected.
> 
> Add and delete packages:
> 
> '.well' 1
> 
> I was expecting the pencil to do the same as other pencils and activate
> text input boxes. Obviously if you're on the Add/Delete packages page
> you can't change the base image like that so maybe not having these
> pencils would be better. I was also unsure as what the change
> version/licence would do.
> 
> '.well' 2
> 
> If you've selected an image recipe and then remove the layer that
> provides it... what happens?
> 
> The Build Image recipe/ Download recipe file / Delete image recipe
> buttons are somewhat easy to miss, they look a bit like progress
> buttons
> or other tabs. I wonder if they would be better off in '.well' 1. The
> Build button could be more noticeable.
> 
> In general if you can avoid having data in a table that for each one
> requires extra data looking up the tables will be much
> faster/efficient.
> For example we have the dependencies button with total size displayed.
> It should be really quick to count the number of dependences, but much
> slower if we also have to retrieve the objects to get the data in them,
> such as "name" and "size".  If we can do that by making it "on demand"
> that's much better, e.g. you click the button and it fetches this extra
> data.
> 
> Thanks,
> 
> Michael
> 
> 
> 
> On 12/06/15 14:40, Barros Pena, Belen wrote:
> > As I mentioned in the Toaster weekly meeting last Wednesday, I've
> recorded
> > a (not so short, sorry) video showing a much more detailed design for
> the
> > image customisation feature. The video is here
> >
> > https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
> customisation.webm
> >
> > Everything that I show in the video is now available in the design
> > prototype at
> >
> > https://yoctoproject.org/toaster
> >
> >
> > Just in case you want to follow along ;)
> >
> > I think the design addresses pretty much all the feedback the Toaster
> > contributors have provided so far (listed below). The only items not
> > addressed are 1 (because it would require us to rethink Toaster as a
> tool
> > for absolute beginners and would impose a very specific workflow) and
> 8
> > (because I haven't had time to think about how we can do this, but we
> can
> > definitely come back to it).
> >
> > Please send any comments and new feedback to the mailing list so that
> > Tiago can collect it and we can address it.
> >
> > This is the feedback we have received so far:
> >
> > 1. Should this kind of linear process be the main Toaster workflow,
> > instead of the non-linear one currently provided by the existing
> project
> > page?
> >
> > 2. Size is project configuration dependent, so all size information
> is a
> > guess, an approximation. We should probably still show it, but the
> > interface needs to present it as such (we need to make sure we don't
> > present it as it was 100% accurate information). The same for
> dependencies.
> >
> > 3. We need to create states for how the tables will look like when
> certain
> > information is missing (number of packages, sizes, etc)
> >
> > 4. We need to refine the recipe presentation in the workflow
> >
> > 5. We need to work on the way we present the actions. Do we really
> need
> > all the ones we have right now?
> >
> > 6. Replace the builds tab with a less prominent way of accessing
> build
> > information for the custom image recipe.
> >
> > 7. Provide a way to reenter the image customisation process from the
> build
> > results
> >
> > 8. Provide a way to 'select all' packages returned by a search
> >
> > 9. Do we need the reverse dependencies information in the packages
> table?
> >
> > 10. Can we add the package size to the visible dependencies
> information in
> > the packages table?
> >
> > 11. The workflow is still too complex: too many concepts exposed
> > (packages, layers, recipes). Should we just require people to build
> the
> > image they want to customise instead?
> >
> > Cheers
> >
> > Belén
> >
> >
> >
> >
> >

Re: [RFC] Image customisation detailed design

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 14418 bytes --]

Hi,

Thanks for putting all this together - very informative and very detailed
mockups. This gave me a great opportunity to review and take in the
interface over the last couple of days, and I thought quite a bit about how
it works.

I'm thinking this over from a bit of a different perspective - please bear
with the consistent comments below. The way the interface is designed now
is - select an image and modify it. This works beautifully if you're pretty
sure about what's in a specified image, and how you want to modify it. The
way I'm seeing it is a bit different - I want to see what would be
installed to the image, and modify the list of packages that are there. The
difference is a bit subtle, but it goes more on the
discoverability/exploratory side, and less on - just add and remove a
couple of packages that I know that are there.

I have some comments of my own, and some replies to the comments below.


1). I think it should be easy to build your own recipes in the
Configuration page. The text entry with the build button should be no
longer the primary means of starting a build, now that we can configure the
build itself.

I would suggest adding a "My image recipes" box in the style of "Most build
recipes" in the Configuration, with two big buttons : "Build selected" and
"New image recipe".



2). For a new user, it's not obvious how to start configuring the image
contents, in the sense that "My image recipes" isn't the most obvious place
one would start to configure a build, which is why people actually look for
into Toaster.

I would suggest making "Type the target you want to build" and Build button
in a section similar to, and on top of the "Latest builds" section. And
add, in that section, in the project page, a bit link "Configure the image
contents".




3). Please drop the "New build" button. That button is a stop-gap measure
to launching build commands, but now we're not simply issue-ing build
commands, we are actually configuring the build. Even if you are an
experienced user, it's opaque form - small and with very little information
- makes it difficult to use.



4). It seems a bit strange that I can navigate to most of the Project
options via the left hand menu, but not to image recipes. The user-defined
image recipes are Project-specific, and I think they are at the same level
with the "Image recipes" and "Software recipes", but in the "CONFIGURATION"
category.

I don't think that having a duplicate link as a tab is a problem, but I get
frustrated by the disappearance of the left-hand-menu in the My Image
Recipes. BTW, thinking of the naming, I would suggest "Custom recipes",
because it's not clear from the links that I can actually configure
something there.



5). When configuring an image, I would suggest dropping the "Base image
recipe" concept, because we can't follow on updates from the base image
recipe after the custom recipe was created, and this will confuse the user.

Also, the tab with the Base image recipe in My Image details, allowing the
user to change the base image for a recipe, should be taken out, since we
cannot change the base image recipe after the initial selection.



6). The "Add A Layer" panel on the right hand side, I would've expected it
to be a pop-up like in the configuration page, not take me to the
Compatible layers. It completely takes me out of the context of what I was
doing - I want to customize a image for MinnowMax, I want to add minnowmax
and be done, not go to a different page, and then have no idea how to
return in a single click.



7). I subscribe to David's view that the popups are annoying and
unnecessary. I would suggest using box alerts as they are currently
implemented, to avoid obscuring the screen, and divert user's attention.
The feedback for immediate actions should not be in your face. Ditto for
the "data loading" spinner, let's make it a bit more obscure.




8). How do I know what's in my image in at a certain moment ? It would be
great if I could have two tables in the image customization page - the
current contents of the image, and the packages that are available. When
selecting/removing a package (maybe we should change the terminology from
Add/Delete?), a package would disappear from a list and appear in the
second one. Also, when deleting / adding a layer in-page, the recipes
available would just appear/disappear from the "available recipes" table.




9). In the "My image recipe", I am not sure why the primary actions that
you can take on the recipe (Build, Download, Delete) are tucked away in the
right hand side, when my focus is on the left hand side, where I get drawn
to the image name. Maybe we can move the buttons, make them bigger, as to
be clear they are the primary action you do with a customized image ?


Cheers,
Alex


On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David <david.reyna@windriver.com>
wrote:

> Hi Belén,
>
> I also appreciate the video and sample Toaster pages!
>
> Here are my comments, in addition to Michael's.
>
> 1) Can we add a filter so that we can show just the packages that we can
> delete?
>

​I suggested to have two tables - one with what's in the image, and one
with what's available. I think this would cover the use case you have in
mind.
​


>
> The use case is trimming the image, where we want the 100 packages that we
> wish to examine for removal not to be lost in the possible 1000's packages
> that are available to add.
>
> 2) I will admit that I was thrown by the new status pop-up, because not
> only does it cover things up on my page, I also generally associate them
> with spam and ad-ware.
>
> I understand your use for showing an action in progress, but we already
> had a metaphor for that in the progress/status bars inserted (when
> applicable) at the top of the page. Why a new metaphor? What does it add
> that the regular model does not? I know that it does stay visible while you
> for example scroll, but is that a hard requirement?
>
> I also do not understand the dangling part, where I have to manual cancel
> it to make it go away. For example, I understand for example its use in the
> add layer parsing progress, but when it is done and says "Layer Information
> updated" why do I have to manually kill it? Could it at least go away on
> its own after a moment, and let that be the clue that the process completed?
>
> The "Undo" feature though is nice!
>

​I'm not sure what the Undo feature is ? Can you give me a bit more details
?
​


>
> 3) The new page can add layers in place which is nice, and I see how you
> can use it to parse and show that layer's package count. However, it
> appears that if I change my mind about the layer I have to go out to the
> layer page to remove it? Could perhaps the "undo" feature also be made
> available here? Or a layer delete icon?
>
> Speaking of layer parsing, don't we already have an idea of the package
> count per layer from the "all packages" table?
>
> 4) How does this interface deal with "package groups"? People will ask.
>
>
> http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks
>
>
> 5) Concerns about package removal
>
> Adding packages is easy, but we (WR) have found that removing them is
> weirdly hard. I am very curious how the backend package removal/exclusion
> is being done, and who is doing it. In any case, we should have disclaimers
> in place.
>

​This is a limitation of the way metadata is structured and tested. Th​e YP
developers often miss correct dependency linking because the actual
dependencies for a package (e.g. installed libraries) were already
satisfied by another chain, so they miss specifying the dependency in the
metadata.

This problem will be re-occuring during Toaster use, and until we clean up
the dependencies metadata, we need to tell the users exactly what's going
on - and enable them to timely submit error reports about the invalid
metadata. This is the only way we can actually clean everything up.


>   * Some removed packages appear anyway in the image, because sometimes
> the dependency information in the packages are not complete nor correct.
>
>   * Some removed packages will break the build or the runtime, even though
> the dependencies say it should be ok. Users should be encouraged to test
> their changes early and often, and we may want to help save their bacon
> with checkpoints (based on the last successful build?) or multiple undo's
> so that they can back up to a working state rather than re-starting from
> scratch. Just saying.
> ​​
>
>
> - David
>
>
> > -----Original Message-----
> > From: toaster-bounces@yoctoproject.org [mailto:toaster-
> > bounces@yoctoproject.org] On Behalf Of Michael Wood
> > Sent: Tuesday, June 23, 2015 9:32 AM
> > To: toaster@yoctoproject.org
> > Subject: Re: [Toaster] [RFC] Image customisation detailed design
> >
> > Thanks for the video Belén, Looks good.
> >
> > Couple of bits of feedback
> >
> > Creating an image recipe:
> >
> > I find the text in the modal too long, anything more than 2 sentences
> > and my attention span is over!
> >
> > I found it confusing that I entered a name and clicked create but have
> > not actually created anything, what about something like
> > suggestion1.png
> > (attached) this brings it more into line with import layer/create new
> > project/form based activity.
> >
> > Select a base image recipe:
> >
> > I was looking for a way to "de/re/select" an image, we don't quite have
> > the same concept here as the machines selection that I was expecting,
> > where you can always select regardless of whether it's already
> > selected.
> >
> > Add and delete packages:
> >
> > '.well' 1
> >
> > I was expecting the pencil to do the same as other pencils and activate
> > text input boxes. Obviously if you're on the Add/Delete packages page
> > you can't change the base image like that so maybe not having these
> > pencils would be better. I was also unsure as what the change
> > version/licence would do.
> >
> > '.well' 2
> >
> > If you've selected an image recipe and then remove the layer that
> > provides it... what happens?
> >
> > The Build Image recipe/ Download recipe file / Delete image recipe
> > buttons are somewhat easy to miss, they look a bit like progress
> > buttons
> > or other tabs. I wonder if they would be better off in '.well' 1. The
> > Build button could be more noticeable.
> >
> > In general if you can avoid having data in a table that for each one
> > requires extra data looking up the tables will be much
> > faster/efficient.
> > For example we have the dependencies button with total size displayed.
> > It should be really quick to count the number of dependences, but much
> > slower if we also have to retrieve the objects to get the data in them,
> > such as "name" and "size".  If we can do that by making it "on demand"
> > that's much better, e.g. you click the button and it fetches this extra
> > data.
> >
> > Thanks,
> >
> > Michael
> >
> >
> >
> > On 12/06/15 14:40, Barros Pena, Belen wrote:
> > > As I mentioned in the Toaster weekly meeting last Wednesday, I've
> > recorded
> > > a (not so short, sorry) video showing a much more detailed design for
> > the
> > > image customisation feature. The video is here
> > >
> > > https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
> > customisation.webm
> > >
> > > Everything that I show in the video is now available in the design
> > > prototype at
> > >
> > > https://yoctoproject.org/toaster
> > >
> > >
> > > Just in case you want to follow along ;)
> > >
> > > I think the design addresses pretty much all the feedback the Toaster
> > > contributors have provided so far (listed below). The only items not
> > > addressed are 1 (because it would require us to rethink Toaster as a
> > tool
> > > for absolute beginners and would impose a very specific workflow) and
> > 8
> > > (because I haven't had time to think about how we can do this, but we
> > can
> > > definitely come back to it).
> > >
> > > Please send any comments and new feedback to the mailing list so that
> > > Tiago can collect it and we can address it.
> > >
> > > This is the feedback we have received so far:
> > >
> > > 1. Should this kind of linear process be the main Toaster workflow,
> > > instead of the non-linear one currently provided by the existing
> > project
> > > page?
> > >
> > > 2. Size is project configuration dependent, so all size information
> > is a
> > > guess, an approximation. We should probably still show it, but the
> > > interface needs to present it as such (we need to make sure we don't
> > > present it as it was 100% accurate information). The same for
> > dependencies.
> > >
> > > 3. We need to create states for how the tables will look like when
> > certain
> > > information is missing (number of packages, sizes, etc)
> > >
> > > 4. We need to refine the recipe presentation in the workflow
> > >
> > > 5. We need to work on the way we present the actions. Do we really
> > need
> > > all the ones we have right now?
> > >
> > > 6. Replace the builds tab with a less prominent way of accessing
> > build
> > > information for the custom image recipe.
> > >
> > > 7. Provide a way to reenter the image customisation process from the
> > build
> > > results
> > >
> > > 8. Provide a way to 'select all' packages returned by a search
> > >
> > > 9. Do we need the reverse dependencies information in the packages
> > table?
> > >
> > > 10. Can we add the package size to the visible dependencies
> > information in
> > > the packages table?
> > >
> > > 11. The workflow is still too complex: too many concepts exposed
> > > (packages, layers, recipes). Should we just require people to build
> > the
> > > image they want to customise instead?
> > >
> > > Cheers
> > >
> > > Belén
> > >
> > >
> > >
> > >
> > >
>
> --
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 22482 bytes --]

Re: [RFC] Image customisation detailed design

[Barros Pena, Belen]

Thanks all for taking the time to look at the design and provide feedback!

I need some time to digest your comments: hopefully we can discuss during
the Toaster meeting either this or next week.

Cheers

Belén

On 26/06/2015 09:31, "Damian, Alexandru" <alexandru.damian@intel.com>
wrote:

>Hi,
>
>
>Thanks for putting all this together - very informative and very detailed
>mockups. This gave me a great opportunity to review and take in the
>interface over the last couple of days, and I thought
> quite a bit about how it works.
>
>
>I'm thinking this over from a bit of a different perspective - please
>bear with the consistent comments below. The way the interface is
>designed now is - select an image and modify it. This works
> beautifully if you're pretty sure about what's in a specified image, and
>how you want to modify it. The way I'm seeing it is a bit different - I
>want to see what would be installed to the image, and modify the list of
>packages that are there. The difference
> is a bit subtle, but it goes more on the discoverability/exploratory
>side, and less on - just add and remove a couple of packages that I know
>that are there.
>
>
>I have some comments of my own, and some replies to the comments below.
>
>
>
>
>1). I think it should be easy to build your own recipes in the
>Configuration page. The text entry with the build button should be no
>longer the primary means of starting a build, now that we can
> configure the build itself.
>
>
>I would suggest adding a "My image recipes" box in the style of "Most
>build recipes" in the Configuration, with two big buttons : "Build
>selected" and "New image recipe".
>
>
>
>
>
>
>2). For a new user, it's not obvious how to start configuring the image
>contents, in the sense that "My image recipes" isn't the most obvious
>place one would start to configure a build, which
> is why people actually look for into Toaster.
>
>
>I would suggest making "Type the target you want to build" and Build
>button in a section similar to, and on top of the "Latest builds"
>section. And add, in that section, in the project page, a
> bit link "Configure the image contents".
>
>
>
>
>
>
>
>
>3). Please drop the "New build" button. That button is a stop-gap measure
>to launching build commands, but now we're not simply issue-ing build
>commands, we are actually configuring the build.
> Even if you are an experienced user, it's opaque form - small and with
>very little information - makes it difficult to use.
>
>
>
>
>
>
>4). It seems a bit strange that I can navigate to most of the Project
>options via the left hand menu, but not to image recipes. The
>user-defined image recipes are Project-specific, and I think
> they are at the same level with the "Image recipes" and "Software
>recipes", but in the "CONFIGURATION" category.
>
>
>I don't think that having a duplicate link as a tab is a problem, but I
>get frustrated by the disappearance of the left-hand-menu in the My Image
>Recipes. BTW, thinking of the naming, I would
> suggest "Custom recipes", because it's not clear from the links that I
>can actually configure something there.
>
>
>
>
>
>
>5). When configuring an image, I would suggest dropping the "Base image
>recipe" concept, because we can't follow on updates from the base image
>recipe after the custom recipe was created, and
> this will confuse the user.
>
>
>Also, the tab with the Base image recipe in My Image details, allowing
>the user to change the base image for a recipe, should be taken out,
>since we cannot change the base image recipe after the
> initial selection.
>
>
>
>
>
>
>6). The "Add A Layer" panel on the right hand side, I would've expected
>it to be a pop-up like in the configuration page, not take me to the
>Compatible layers. It completely takes me out of the
> context of what I was doing - I want to customize a image for MinnowMax,
>I want to add minnowmax and be done, not go to a different page, and then
>have no idea how to return in a single click.
>
>
>
>
>
>
>7). I subscribe to David's view that the popups are annoying and
>unnecessary. I would suggest using box alerts as they are currently
>implemented, to avoid obscuring the screen, and divert user's
> attention. The feedback for immediate actions should not be in your
>face. Ditto for the "data loading" spinner, let's make it a bit more
>obscure. 
>
>
>
>
>
>
>
>
>8). How do I know what's in my image in at a certain moment ? It would be
>great if I could have two tables in the image customization page - the
>current contents of the image, and the packages
> that are available. When selecting/removing a package (maybe we should
>change the terminology from Add/Delete?), a package would disappear from
>a list and appear in the second one. Also, when deleting / adding a layer
>in-page, the recipes available would just
> appear/disappear from the "available recipes" table.
>
>
>
>
>
>
>
>
>9). In the "My image recipe", I am not sure why the primary actions that
>you can take on the recipe (Build, Download, Delete) are tucked away in
>the right hand side, when my focus is on the left
> hand side, where I get drawn to the image name. Maybe we can move the
>buttons, make them bigger, as to be clear they are the primary action you
>do with a customized image ?
>
>
>
>
>Cheers,
>Alex
>
>
>
>
>On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David
><david.reyna@windriver.com> wrote:
>
>Hi Belén,
>
>I also appreciate the video and sample Toaster pages!
>
>Here are my comments, in addition to Michael's.
>
>1) Can we add a filter so that we can show just the packages that we can
>delete?
>
>
>
>
>​I suggested to have two tables - one with what's in the image, and one
>with what's available. I think this would cover the use case you have in
>mind.
>
>​
> 
>
>
>The use case is trimming the image, where we want the 100 packages that
>we wish to examine for removal not to be lost in the possible 1000's
>packages that are available to add.
>
>2) I will admit that I was thrown by the new status pop-up, because not
>only does it cover things up on my page, I also generally associate them
>with spam and ad-ware.
>
>I understand your use for showing an action in progress, but we already
>had a metaphor for that in the progress/status bars inserted (when
>applicable) at the top of the page. Why a new metaphor? What does it add
>that the regular model does not? I know that
> it does stay visible while you for example scroll, but is that a hard
>requirement?
>
>I also do not understand the dangling part, where I have to manual cancel
>it to make it go away. For example, I understand for example its use in
>the add layer parsing progress, but when it is done and says "Layer
>Information updated" why do I have to manually
> kill it? Could it at least go away on its own after a moment, and let
>that be the clue that the process completed?
>
>The "Undo" feature though is nice!
>
>
>
>
>​I'm not sure what the Undo feature is ? Can you give me a bit more
>details ?
>
>​
> 
>
>
>3) The new page can add layers in place which is nice, and I see how you
>can use it to parse and show that layer's package count. However, it
>appears that if I change my mind about the layer I have to go out to the
>layer page to remove it? Could perhaps the
> "undo" feature also be made available here? Or a layer delete icon?
>
>Speaking of layer parsing, don't we already have an idea of the package
>count per layer from the "all packages" table?
>
>4) How does this interface deal with "package groups"? People will ask.
>
>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-
>extend-customimage-customtasks
>
>
>5) Concerns about package removal
>
>Adding packages is easy, but we (WR) have found that removing them is
>weirdly hard. I am very curious how the backend package removal/exclusion
>is being done, and who is doing it. In any case, we should have
>disclaimers in place.
>
>
>
>
>​This is a limitation of the way metadata is structured and tested. Th​e
>YP developers often miss correct dependency linking because the actual
>dependencies for a package (e.g.
> installed libraries) were already satisfied by another chain, so they
>miss specifying the dependency in the metadata.
>
>
>
>
>This problem will be re-occuring during Toaster use, and until we clean
>up the dependencies metadata, we need to tell the users exactly what's
>going on - and enable them to timely
> submit error reports about the invalid metadata. This is the only way we
>can actually clean everything up.
>
>
>
>
>
>
>  * Some removed packages appear anyway in the image, because sometimes
>the dependency information in the packages are not complete nor correct.
>
>  * Some removed packages will break the build or the runtime, even
>though the dependencies say it should be ok. Users should be encouraged
>to test their changes early and often, and we may want to help save their
>bacon with checkpoints (based on the last successful
> build?) or multiple undo's so that they can back up to a working state
>rather than re-starting from scratch. Just saying.
>​​
>
>
>- David
>
>
>> -----Original Message-----
>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
>> bounces@yoctoproject.org] On Behalf Of Michael Wood
>> Sent: Tuesday, June 23, 2015 9:32 AM
>> To: toaster@yoctoproject.org
>> Subject: Re: [Toaster] [RFC] Image customisation detailed design
>>
>> Thanks for the video Belén, Looks good.
>>
>> Couple of bits of feedback
>>
>> Creating an image recipe:
>>
>> I find the text in the modal too long, anything more than 2 sentences
>> and my attention span is over!
>>
>> I found it confusing that I entered a name and clicked create but have
>> not actually created anything, what about something like
>> suggestion1.png
>> (attached) this brings it more into line with import layer/create new
>> project/form based activity.
>>
>> Select a base image recipe:
>>
>> I was looking for a way to "de/re/select" an image, we don't quite have
>> the same concept here as the machines selection that I was expecting,
>> where you can always select regardless of whether it's already
>> selected.
>>
>> Add and delete packages:
>>
>> '.well' 1
>>
>> I was expecting the pencil to do the same as other pencils and activate
>> text input boxes. Obviously if you're on the Add/Delete packages page
>> you can't change the base image like that so maybe not having these
>> pencils would be better. I was also unsure as what the change
>> version/licence would do.
>>
>> '.well' 2
>>
>> If you've selected an image recipe and then remove the layer that
>> provides it... what happens?
>>
>> The Build Image recipe/ Download recipe file / Delete image recipe
>> buttons are somewhat easy to miss, they look a bit like progress
>> buttons
>> or other tabs. I wonder if they would be better off in '.well' 1. The
>> Build button could be more noticeable.
>>
>> In general if you can avoid having data in a table that for each one
>> requires extra data looking up the tables will be much
>> faster/efficient.
>> For example we have the dependencies button with total size displayed.
>> It should be really quick to count the number of dependences, but much
>> slower if we also have to retrieve the objects to get the data in them,
>> such as "name" and "size".  If we can do that by making it "on demand"
>> that's much better, e.g. you click the button and it fetches this extra
>> data.
>>
>> Thanks,
>>
>> Michael
>>
>>
>>
>> On 12/06/15 14:40, Barros Pena, Belen wrote:
>> > As I mentioned in the Toaster weekly meeting last Wednesday, I've
>> recorded
>> > a (not so short, sorry) video showing a much more detailed design for
>> the
>> > image customisation feature. The video is here
>> >
>> > 
>https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
><https://wiki.yoctoproject.org/wiki/images/a/a1/Image->
>> customisation.webm
>> >
>> > Everything that I show in the video is now available in the design
>> > prototype at
>> >
>> > https://yoctoproject.org/toaster
>> >
>> >
>> > Just in case you want to follow along ;)
>> >
>> > I think the design addresses pretty much all the feedback the Toaster
>> > contributors have provided so far (listed below). The only items not
>> > addressed are 1 (because it would require us to rethink Toaster as a
>> tool
>> > for absolute beginners and would impose a very specific workflow) and
>> 8
>> > (because I haven't had time to think about how we can do this, but we
>> can
>> > definitely come back to it).
>> >
>> > Please send any comments and new feedback to the mailing list so that
>> > Tiago can collect it and we can address it.
>> >
>> > This is the feedback we have received so far:
>> >
>> > 1. Should this kind of linear process be the main Toaster workflow,
>> > instead of the non-linear one currently provided by the existing
>> project
>> > page?
>> >
>> > 2. Size is project configuration dependent, so all size information
>> is a
>> > guess, an approximation. We should probably still show it, but the
>> > interface needs to present it as such (we need to make sure we don't
>> > present it as it was 100% accurate information). The same for
>> dependencies.
>> >
>> > 3. We need to create states for how the tables will look like when
>> certain
>> > information is missing (number of packages, sizes, etc)
>> >
>> > 4. We need to refine the recipe presentation in the workflow
>> >
>> > 5. We need to work on the way we present the actions. Do we really
>> need
>> > all the ones we have right now?
>> >
>> > 6. Replace the builds tab with a less prominent way of accessing
>> build
>> > information for the custom image recipe.
>> >
>> > 7. Provide a way to reenter the image customisation process from the
>> build
>> > results
>> >
>> > 8. Provide a way to 'select all' packages returned by a search
>> >
>> > 9. Do we need the reverse dependencies information in the packages
>> table?
>> >
>> > 10. Can we add the package size to the visible dependencies
>> information in
>> > the packages table?
>> >
>> > 11. The workflow is still too complex: too many concepts exposed
>> > (packages, layers, recipes). Should we just require people to build
>> the
>> > image they want to customise instead?
>> >
>> > Cheers
>> >
>> > Belén
>> >
>> >
>> >
>> >
>> >
>
>
>
>--
>_______________________________________________
>toaster mailing list
>toaster@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>
>
>
>
>
>
>-- 
>Alex Damian
>Yocto Project
>
>SSG / OTC 
>
>
>
>

Re: [RFC] Image customisation detailed design

[Barros Pena, Belen]

I finally had a chance to work through your feedback for the image
customisation design. I've grouped it into categories and replied to each
of the comments. It is long, so I've transferred it to a wiki page

https://wiki.yoctoproject.org/wiki/Design_feedback

Search in page for your names if you want to see the answers to the issues
you raised. Edit the page if you want to reply to any of them, or reply
here (whichever is easier for you).

There a few design ARs coming out of it all. The list is in

https://wiki.yoctoproject.org/wiki/Design_feedback#Design_ARs

I will be working through those next week.

Thanks all for your design review!

Belén
 

On 30/06/2015 13:58, "Barros Pena, Belen" <belen.barros.pena@intel.com>
wrote:

>Thanks all for taking the time to look at the design and provide feedback!
>
>I need some time to digest your comments: hopefully we can discuss during
>the Toaster meeting either this or next week.
>
>Cheers
>
>Belén
>
>On 26/06/2015 09:31, "Damian, Alexandru" <alexandru.damian@intel.com>
>wrote:
>
>>Hi,
>>
>>
>>Thanks for putting all this together - very informative and very detailed
>>mockups. This gave me a great opportunity to review and take in the
>>interface over the last couple of days, and I thought
>> quite a bit about how it works.
>>
>>
>>I'm thinking this over from a bit of a different perspective - please
>>bear with the consistent comments below. The way the interface is
>>designed now is - select an image and modify it. This works
>> beautifully if you're pretty sure about what's in a specified image, and
>>how you want to modify it. The way I'm seeing it is a bit different - I
>>want to see what would be installed to the image, and modify the list of
>>packages that are there. The difference
>> is a bit subtle, but it goes more on the discoverability/exploratory
>>side, and less on - just add and remove a couple of packages that I know
>>that are there.
>>
>>
>>I have some comments of my own, and some replies to the comments below.
>>
>>
>>
>>
>>1). I think it should be easy to build your own recipes in the
>>Configuration page. The text entry with the build button should be no
>>longer the primary means of starting a build, now that we can
>> configure the build itself.
>>
>>
>>I would suggest adding a "My image recipes" box in the style of "Most
>>build recipes" in the Configuration, with two big buttons : "Build
>>selected" and "New image recipe".
>>
>>
>>
>>
>>
>>
>>2). For a new user, it's not obvious how to start configuring the image
>>contents, in the sense that "My image recipes" isn't the most obvious
>>place one would start to configure a build, which
>> is why people actually look for into Toaster.
>>
>>
>>I would suggest making "Type the target you want to build" and Build
>>button in a section similar to, and on top of the "Latest builds"
>>section. And add, in that section, in the project page, a
>> bit link "Configure the image contents".
>>
>>
>>
>>
>>
>>
>>
>>
>>3). Please drop the "New build" button. That button is a stop-gap measure
>>to launching build commands, but now we're not simply issue-ing build
>>commands, we are actually configuring the build.
>> Even if you are an experienced user, it's opaque form - small and with
>>very little information - makes it difficult to use.
>>
>>
>>
>>
>>
>>
>>4). It seems a bit strange that I can navigate to most of the Project
>>options via the left hand menu, but not to image recipes. The
>>user-defined image recipes are Project-specific, and I think
>> they are at the same level with the "Image recipes" and "Software
>>recipes", but in the "CONFIGURATION" category.
>>
>>
>>I don't think that having a duplicate link as a tab is a problem, but I
>>get frustrated by the disappearance of the left-hand-menu in the My Image
>>Recipes. BTW, thinking of the naming, I would
>> suggest "Custom recipes", because it's not clear from the links that I
>>can actually configure something there.
>>
>>
>>
>>
>>
>>
>>5). When configuring an image, I would suggest dropping the "Base image
>>recipe" concept, because we can't follow on updates from the base image
>>recipe after the custom recipe was created, and
>> this will confuse the user.
>>
>>
>>Also, the tab with the Base image recipe in My Image details, allowing
>>the user to change the base image for a recipe, should be taken out,
>>since we cannot change the base image recipe after the
>> initial selection.
>>
>>
>>
>>
>>
>>
>>6). The "Add A Layer" panel on the right hand side, I would've expected
>>it to be a pop-up like in the configuration page, not take me to the
>>Compatible layers. It completely takes me out of the
>> context of what I was doing - I want to customize a image for MinnowMax,
>>I want to add minnowmax and be done, not go to a different page, and then
>>have no idea how to return in a single click.
>>
>>
>>
>>
>>
>>
>>7). I subscribe to David's view that the popups are annoying and
>>unnecessary. I would suggest using box alerts as they are currently
>>implemented, to avoid obscuring the screen, and divert user's
>> attention. The feedback for immediate actions should not be in your
>>face. Ditto for the "data loading" spinner, let's make it a bit more
>>obscure. 
>>
>>
>>
>>
>>
>>
>>
>>
>>8). How do I know what's in my image in at a certain moment ? It would be
>>great if I could have two tables in the image customization page - the
>>current contents of the image, and the packages
>> that are available. When selecting/removing a package (maybe we should
>>change the terminology from Add/Delete?), a package would disappear from
>>a list and appear in the second one. Also, when deleting / adding a layer
>>in-page, the recipes available would just
>> appear/disappear from the "available recipes" table.
>>
>>
>>
>>
>>
>>
>>
>>
>>9). In the "My image recipe", I am not sure why the primary actions that
>>you can take on the recipe (Build, Download, Delete) are tucked away in
>>the right hand side, when my focus is on the left
>> hand side, where I get drawn to the image name. Maybe we can move the
>>buttons, make them bigger, as to be clear they are the primary action you
>>do with a customized image ?
>>
>>
>>
>>
>>Cheers,
>>Alex
>>
>>
>>
>>
>>On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David
>><david.reyna@windriver.com> wrote:
>>
>>Hi Belén,
>>
>>I also appreciate the video and sample Toaster pages!
>>
>>Here are my comments, in addition to Michael's.
>>
>>1) Can we add a filter so that we can show just the packages that we can
>>delete?
>>
>>
>>
>>
>>​I suggested to have two tables - one with what's in the image, and one
>>with what's available. I think this would cover the use case you have in
>>mind.
>>
>>​
>> 
>>
>>
>>The use case is trimming the image, where we want the 100 packages that
>>we wish to examine for removal not to be lost in the possible 1000's
>>packages that are available to add.
>>
>>2) I will admit that I was thrown by the new status pop-up, because not
>>only does it cover things up on my page, I also generally associate them
>>with spam and ad-ware.
>>
>>I understand your use for showing an action in progress, but we already
>>had a metaphor for that in the progress/status bars inserted (when
>>applicable) at the top of the page. Why a new metaphor? What does it add
>>that the regular model does not? I know that
>> it does stay visible while you for example scroll, but is that a hard
>>requirement?
>>
>>I also do not understand the dangling part, where I have to manual cancel
>>it to make it go away. For example, I understand for example its use in
>>the add layer parsing progress, but when it is done and says "Layer
>>Information updated" why do I have to manually
>> kill it? Could it at least go away on its own after a moment, and let
>>that be the clue that the process completed?
>>
>>The "Undo" feature though is nice!
>>
>>
>>
>>
>>​I'm not sure what the Undo feature is ? Can you give me a bit more
>>details ?
>>
>>​
>> 
>>
>>
>>3) The new page can add layers in place which is nice, and I see how you
>>can use it to parse and show that layer's package count. However, it
>>appears that if I change my mind about the layer I have to go out to the
>>layer page to remove it? Could perhaps the
>> "undo" feature also be made available here? Or a layer delete icon?
>>
>>Speaking of layer parsing, don't we already have an idea of the package
>>count per layer from the "all packages" table?
>>
>>4) How does this interface deal with "package groups"? People will ask.
>>
>>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky
>>-
>>extend-customimage-customtasks
>>
>>
>>5) Concerns about package removal
>>
>>Adding packages is easy, but we (WR) have found that removing them is
>>weirdly hard. I am very curious how the backend package removal/exclusion
>>is being done, and who is doing it. In any case, we should have
>>disclaimers in place.
>>
>>
>>
>>
>>​This is a limitation of the way metadata is structured and tested. Th​e
>>YP developers often miss correct dependency linking because the actual
>>dependencies for a package (e.g.
>> installed libraries) were already satisfied by another chain, so they
>>miss specifying the dependency in the metadata.
>>
>>
>>
>>
>>This problem will be re-occuring during Toaster use, and until we clean
>>up the dependencies metadata, we need to tell the users exactly what's
>>going on - and enable them to timely
>> submit error reports about the invalid metadata. This is the only way we
>>can actually clean everything up.
>>
>>
>>
>>
>>
>>
>>  * Some removed packages appear anyway in the image, because sometimes
>>the dependency information in the packages are not complete nor correct.
>>
>>  * Some removed packages will break the build or the runtime, even
>>though the dependencies say it should be ok. Users should be encouraged
>>to test their changes early and often, and we may want to help save their
>>bacon with checkpoints (based on the last successful
>> build?) or multiple undo's so that they can back up to a working state
>>rather than re-starting from scratch. Just saying.
>>​​
>>
>>
>>- David
>>
>>
>>> -----Original Message-----
>>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
>>> bounces@yoctoproject.org] On Behalf Of Michael Wood
>>> Sent: Tuesday, June 23, 2015 9:32 AM
>>> To: toaster@yoctoproject.org
>>> Subject: Re: [Toaster] [RFC] Image customisation detailed design
>>>
>>> Thanks for the video Belén, Looks good.
>>>
>>> Couple of bits of feedback
>>>
>>> Creating an image recipe:
>>>
>>> I find the text in the modal too long, anything more than 2 sentences
>>> and my attention span is over!
>>>
>>> I found it confusing that I entered a name and clicked create but have
>>> not actually created anything, what about something like
>>> suggestion1.png
>>> (attached) this brings it more into line with import layer/create new
>>> project/form based activity.
>>>
>>> Select a base image recipe:
>>>
>>> I was looking for a way to "de/re/select" an image, we don't quite have
>>> the same concept here as the machines selection that I was expecting,
>>> where you can always select regardless of whether it's already
>>> selected.
>>>
>>> Add and delete packages:
>>>
>>> '.well' 1
>>>
>>> I was expecting the pencil to do the same as other pencils and activate
>>> text input boxes. Obviously if you're on the Add/Delete packages page
>>> you can't change the base image like that so maybe not having these
>>> pencils would be better. I was also unsure as what the change
>>> version/licence would do.
>>>
>>> '.well' 2
>>>
>>> If you've selected an image recipe and then remove the layer that
>>> provides it... what happens?
>>>
>>> The Build Image recipe/ Download recipe file / Delete image recipe
>>> buttons are somewhat easy to miss, they look a bit like progress
>>> buttons
>>> or other tabs. I wonder if they would be better off in '.well' 1. The
>>> Build button could be more noticeable.
>>>
>>> In general if you can avoid having data in a table that for each one
>>> requires extra data looking up the tables will be much
>>> faster/efficient.
>>> For example we have the dependencies button with total size displayed.
>>> It should be really quick to count the number of dependences, but much
>>> slower if we also have to retrieve the objects to get the data in them,
>>> such as "name" and "size".  If we can do that by making it "on demand"
>>> that's much better, e.g. you click the button and it fetches this extra
>>> data.
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>>
>>> On 12/06/15 14:40, Barros Pena, Belen wrote:
>>> > As I mentioned in the Toaster weekly meeting last Wednesday, I've
>>> recorded
>>> > a (not so short, sorry) video showing a much more detailed design for
>>> the
>>> > image customisation feature. The video is here
>>> >
>>> > 
>>https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
>><https://wiki.yoctoproject.org/wiki/images/a/a1/Image->
>>> customisation.webm
>>> >
>>> > Everything that I show in the video is now available in the design
>>> > prototype at
>>> >
>>> > https://yoctoproject.org/toaster
>>> >
>>> >
>>> > Just in case you want to follow along ;)
>>> >
>>> > I think the design addresses pretty much all the feedback the Toaster
>>> > contributors have provided so far (listed below). The only items not
>>> > addressed are 1 (because it would require us to rethink Toaster as a
>>> tool
>>> > for absolute beginners and would impose a very specific workflow) and
>>> 8
>>> > (because I haven't had time to think about how we can do this, but we
>>> can
>>> > definitely come back to it).
>>> >
>>> > Please send any comments and new feedback to the mailing list so that
>>> > Tiago can collect it and we can address it.
>>> >
>>> > This is the feedback we have received so far:
>>> >
>>> > 1. Should this kind of linear process be the main Toaster workflow,
>>> > instead of the non-linear one currently provided by the existing
>>> project
>>> > page?
>>> >
>>> > 2. Size is project configuration dependent, so all size information
>>> is a
>>> > guess, an approximation. We should probably still show it, but the
>>> > interface needs to present it as such (we need to make sure we don't
>>> > present it as it was 100% accurate information). The same for
>>> dependencies.
>>> >
>>> > 3. We need to create states for how the tables will look like when
>>> certain
>>> > information is missing (number of packages, sizes, etc)
>>> >
>>> > 4. We need to refine the recipe presentation in the workflow
>>> >
>>> > 5. We need to work on the way we present the actions. Do we really
>>> need
>>> > all the ones we have right now?
>>> >
>>> > 6. Replace the builds tab with a less prominent way of accessing
>>> build
>>> > information for the custom image recipe.
>>> >
>>> > 7. Provide a way to reenter the image customisation process from the
>>> build
>>> > results
>>> >
>>> > 8. Provide a way to 'select all' packages returned by a search
>>> >
>>> > 9. Do we need the reverse dependencies information in the packages
>>> table?
>>> >
>>> > 10. Can we add the package size to the visible dependencies
>>> information in
>>> > the packages table?
>>> >
>>> > 11. The workflow is still too complex: too many concepts exposed
>>> > (packages, layers, recipes). Should we just require people to build
>>> the
>>> > image they want to customise instead?
>>> >
>>> > Cheers
>>> >
>>> > Belén
>>> >
>>> >
>>> >
>>> >
>>> >
>>
>>
>>
>>--
>>_______________________________________________
>>toaster mailing list
>>toaster@yoctoproject.org
>>https://lists.yoctoproject.org/listinfo/toaster
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-- 
>>Alex Damian
>>Yocto Project
>>
>>SSG / OTC 
>>
>>
>>
>>
>
>-- 
>_______________________________________________
>toaster mailing list
>toaster@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster

Re: [RFC] Image customisation detailed design

[Ed Bartosh]

Hi Belen,

Sorry for the late feedback.

Thank you for the nice and clear explanations and the video. It helped
me a lot to understand UI design of the image customization.
Despite my notices below I like the UI and overall concept. It
looks much cleaner than before. Thank you.

I decided to send my feedback to the mailing list as I don't have account
on Yocto wiki yet.

MICHAEL: I found it confusing that I entered a name and clicked create
but have not actually created anything
BELEN: mmm, this one is interesting. What makes you think that you have
not created anything?
ED: I agree with MICHAEL. This step doesn't create anything, but the
name. Can we make choosing base image as a mandatory step or merge it
with naming somehow?

ALEX: When configuring an image, I would suggest dropping the "Base
image recipe" concept, because we can't follow on updates from the base
image recipe after the custom recipe was created, and this will confuse
the user.
BELEN: and what do users do instead? Do they start they custom image
recipes from a blank slate? That will most likely result in an image
that doesn't build. Do you have an alternative starting point in mind?
ALEX: The users would start from an already existing image, as they do
now. What I'm suggesting is dropping the tab of possible base images,
and the ability to change the base image for a custom image once the
custom image recipe is created. This is the same point as below, just
pointing to the tab.
ED: This would make sense to do as we're not tracking relationship
between base and custom image after creation of custom image.
People may get a wrong idea of tracking changes of base image in
customized image if we keep showing base image name. It should be made
clear that we're using base image only for fetching list of packages
when we create custom image. Creation of custom image can be done
similar to custimizing file in editor using 'Save as'. Users have to
pick up base file and have to save it with the new name if they want
to make a customizable copy of it. After that relationship between
base file and custom one is lost. Can we do something similar?

MICHAEL: In general if you can avoid having data in a table that for
each one requires extra data looking up the tables will be much
faster/efficient. For example we have the dependencies button with total
size displayed. It should be really quick to count the number of
dependences, but much slower if we also have to retrieve the objects to
get the data in them, such as "name" and "size". If we can do that by
making it "on demand" that's much better, e.g. you click the button and
it fetches this extra data.
BELEN: this was my initial approach. From the UI perspective, it is also
tidier. Then Ed asked to see this information without having to click,
and I decided to give it a try to see how it would look like. I agree it
is better to present it when you select a certain dependency, so I will
revert to that. Sorry Ed :/
ED: I tend to disagree with this. Size of the components is very
important information when choosing base image. I agree that it should
not be shown in the table as it'd slow UI down. However, this
information is only shown when user presses the button with the number of
dependencies.

DAVID: How does this interface deal with "package groups"? People will
ask.
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks
BELEN: I'm afraid it doesn't. We know that at some point we'll need to
distinguish package groups from other recipes, and break them up, i.e.
allow people to remove packages from package groups. But during the high
level design discussions we came to the conclusion that it would be too
hard to do in version 1 - see page 11 of the initial design document
https://wiki.yoctoproject.org/wiki/images/3/31/Image_customisation_in_Toaster.pdf
ED: Looking at existing image recipes I see "IMAGE_FEATURES +=" lines almost
in all of them. This makes me think that most of the time images are
customized by adding feature/groups. I think David is right here -
people will definitely ask for this. It's just much more convenient,
faster and understandable to deal with well defined components than with
packages. For example IMAGE_FEATURES += "splash ssh-server-openssh hwcodecs
package-management" is quite straightforward and clear to me. It would
require user to pick up 4 groups from the list of groups with clear
names. However, it's much harder to say how many and which packages to
pick up to add this functionality to the image. I'm afraid without
introducing groups we'll make image customization different from how
it's done in real life and much harder that it should be.

Additional questions:

Adding / removing layers: Would it make sense to not allow users to
remove layers if custom images use recipes from them? Or at least
notify user which recipes from the layer are used in custom images?

There are a lot of variables available for tweaking
in image recipesi: SUMMARY, DESCRIPTION, IMAGE_FSTYPES, etc.
Are we going to allow changing them or allow editing recipes for custom
images?

Current set of image recipes uses single and multiple inheritance of
other image recipes. Are we going to show inheritance tree and allow
inheritance in custom recipes?

Regards,
Ed

On Fri, Jul 03, 2015 at 03:42:58PM +0000, Barros Pena, Belen wrote:
> I finally had a chance to work through your feedback for the image
> customisation design. I've grouped it into categories and replied to each
> of the comments. It is long, so I've transferred it to a wiki page
> 
> https://wiki.yoctoproject.org/wiki/Design_feedback
> 
> Search in page for your names if you want to see the answers to the issues
> you raised. Edit the page if you want to reply to any of them, or reply
> here (whichever is easier for you).
> 
> There a few design ARs coming out of it all. The list is in
> 
> https://wiki.yoctoproject.org/wiki/Design_feedback#Design_ARs
> 
> I will be working through those next week.
> 
> Thanks all for your design review!
> 
> Belén
>  
> 
> On 30/06/2015 13:58, "Barros Pena, Belen" <belen.barros.pena@intel.com>
> wrote:
> 
> >Thanks all for taking the time to look at the design and provide feedback!
> >
> >I need some time to digest your comments: hopefully we can discuss during
> >the Toaster meeting either this or next week.
> >
> >Cheers
> >
> >Belén
> >
> >On 26/06/2015 09:31, "Damian, Alexandru" <alexandru.damian@intel.com>
> >wrote:
> >
> >>Hi,
> >>
> >>
> >>Thanks for putting all this together - very informative and very detailed
> >>mockups. This gave me a great opportunity to review and take in the
> >>interface over the last couple of days, and I thought
> >> quite a bit about how it works.
> >>
> >>
> >>I'm thinking this over from a bit of a different perspective - please
> >>bear with the consistent comments below. The way the interface is
> >>designed now is - select an image and modify it. This works
> >> beautifully if you're pretty sure about what's in a specified image, and
> >>how you want to modify it. The way I'm seeing it is a bit different - I
> >>want to see what would be installed to the image, and modify the list of
> >>packages that are there. The difference
> >> is a bit subtle, but it goes more on the discoverability/exploratory
> >>side, and less on - just add and remove a couple of packages that I know
> >>that are there.
> >>
> >>
> >>I have some comments of my own, and some replies to the comments below.
> >>
> >>
> >>
> >>
> >>1). I think it should be easy to build your own recipes in the
> >>Configuration page. The text entry with the build button should be no
> >>longer the primary means of starting a build, now that we can
> >> configure the build itself.
> >>
> >>
> >>I would suggest adding a "My image recipes" box in the style of "Most
> >>build recipes" in the Configuration, with two big buttons : "Build
> >>selected" and "New image recipe".
> >>
> >>
> >>
> >>
> >>
> >>
> >>2). For a new user, it's not obvious how to start configuring the image
> >>contents, in the sense that "My image recipes" isn't the most obvious
> >>place one would start to configure a build, which
> >> is why people actually look for into Toaster.
> >>
> >>
> >>I would suggest making "Type the target you want to build" and Build
> >>button in a section similar to, and on top of the "Latest builds"
> >>section. And add, in that section, in the project page, a
> >> bit link "Configure the image contents".
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>3). Please drop the "New build" button. That button is a stop-gap measure
> >>to launching build commands, but now we're not simply issue-ing build
> >>commands, we are actually configuring the build.
> >> Even if you are an experienced user, it's opaque form - small and with
> >>very little information - makes it difficult to use.
> >>
> >>
> >>
> >>
> >>
> >>
> >>4). It seems a bit strange that I can navigate to most of the Project
> >>options via the left hand menu, but not to image recipes. The
> >>user-defined image recipes are Project-specific, and I think
> >> they are at the same level with the "Image recipes" and "Software
> >>recipes", but in the "CONFIGURATION" category.
> >>
> >>
> >>I don't think that having a duplicate link as a tab is a problem, but I
> >>get frustrated by the disappearance of the left-hand-menu in the My Image
> >>Recipes. BTW, thinking of the naming, I would
> >> suggest "Custom recipes", because it's not clear from the links that I
> >>can actually configure something there.
> >>
> >>
> >>
> >>
> >>
> >>
> >>5). When configuring an image, I would suggest dropping the "Base image
> >>recipe" concept, because we can't follow on updates from the base image
> >>recipe after the custom recipe was created, and
> >> this will confuse the user.
> >>
> >>
> >>Also, the tab with the Base image recipe in My Image details, allowing
> >>the user to change the base image for a recipe, should be taken out,
> >>since we cannot change the base image recipe after the
> >> initial selection.
> >>
> >>
> >>
> >>
> >>
> >>
> >>6). The "Add A Layer" panel on the right hand side, I would've expected
> >>it to be a pop-up like in the configuration page, not take me to the
> >>Compatible layers. It completely takes me out of the
> >> context of what I was doing - I want to customize a image for MinnowMax,
> >>I want to add minnowmax and be done, not go to a different page, and then
> >>have no idea how to return in a single click.
> >>
> >>
> >>
> >>
> >>
> >>
> >>7). I subscribe to David's view that the popups are annoying and
> >>unnecessary. I would suggest using box alerts as they are currently
> >>implemented, to avoid obscuring the screen, and divert user's
> >> attention. The feedback for immediate actions should not be in your
> >>face. Ditto for the "data loading" spinner, let's make it a bit more
> >>obscure. 
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>8). How do I know what's in my image in at a certain moment ? It would be
> >>great if I could have two tables in the image customization page - the
> >>current contents of the image, and the packages
> >> that are available. When selecting/removing a package (maybe we should
> >>change the terminology from Add/Delete?), a package would disappear from
> >>a list and appear in the second one. Also, when deleting / adding a layer
> >>in-page, the recipes available would just
> >> appear/disappear from the "available recipes" table.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>9). In the "My image recipe", I am not sure why the primary actions that
> >>you can take on the recipe (Build, Download, Delete) are tucked away in
> >>the right hand side, when my focus is on the left
> >> hand side, where I get drawn to the image name. Maybe we can move the
> >>buttons, make them bigger, as to be clear they are the primary action you
> >>do with a customized image ?
> >>
> >>
> >>
> >>
> >>Cheers,
> >>Alex
> >>
> >>
> >>
> >>
> >>On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David
> >><david.reyna@windriver.com> wrote:
> >>
> >>Hi Belén,
> >>
> >>I also appreciate the video and sample Toaster pages!
> >>
> >>Here are my comments, in addition to Michael's.
> >>
> >>1) Can we add a filter so that we can show just the packages that we can
> >>delete?
> >>
> >>
> >>
> >>
> >>​I suggested to have two tables - one with what's in the image, and one
> >>with what's available. I think this would cover the use case you have in
> >>mind.
> >>
> >>​
> >> 
> >>
> >>
> >>The use case is trimming the image, where we want the 100 packages that
> >>we wish to examine for removal not to be lost in the possible 1000's
> >>packages that are available to add.
> >>
> >>2) I will admit that I was thrown by the new status pop-up, because not
> >>only does it cover things up on my page, I also generally associate them
> >>with spam and ad-ware.
> >>
> >>I understand your use for showing an action in progress, but we already
> >>had a metaphor for that in the progress/status bars inserted (when
> >>applicable) at the top of the page. Why a new metaphor? What does it add
> >>that the regular model does not? I know that
> >> it does stay visible while you for example scroll, but is that a hard
> >>requirement?
> >>
> >>I also do not understand the dangling part, where I have to manual cancel
> >>it to make it go away. For example, I understand for example its use in
> >>the add layer parsing progress, but when it is done and says "Layer
> >>Information updated" why do I have to manually
> >> kill it? Could it at least go away on its own after a moment, and let
> >>that be the clue that the process completed?
> >>
> >>The "Undo" feature though is nice!
> >>
> >>
> >>
> >>
> >>​I'm not sure what the Undo feature is ? Can you give me a bit more
> >>details ?
> >>
> >>​
> >> 
> >>
> >>
> >>3) The new page can add layers in place which is nice, and I see how you
> >>can use it to parse and show that layer's package count. However, it
> >>appears that if I change my mind about the layer I have to go out to the
> >>layer page to remove it? Could perhaps the
> >> "undo" feature also be made available here? Or a layer delete icon?
> >>
> >>Speaking of layer parsing, don't we already have an idea of the package
> >>count per layer from the "all packages" table?
> >>
> >>4) How does this interface deal with "package groups"? People will ask.
> >>
> >>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky
> >>-
> >>extend-customimage-customtasks
> >>
> >>
> >>5) Concerns about package removal
> >>
> >>Adding packages is easy, but we (WR) have found that removing them is
> >>weirdly hard. I am very curious how the backend package removal/exclusion
> >>is being done, and who is doing it. In any case, we should have
> >>disclaimers in place.
> >>
> >>
> >>
> >>
> >>​This is a limitation of the way metadata is structured and tested. Th​e
> >>YP developers often miss correct dependency linking because the actual
> >>dependencies for a package (e.g.
> >> installed libraries) were already satisfied by another chain, so they
> >>miss specifying the dependency in the metadata.
> >>
> >>
> >>
> >>
> >>This problem will be re-occuring during Toaster use, and until we clean
> >>up the dependencies metadata, we need to tell the users exactly what's
> >>going on - and enable them to timely
> >> submit error reports about the invalid metadata. This is the only way we
> >>can actually clean everything up.
> >>
> >>
> >>
> >>
> >>
> >>
> >>  * Some removed packages appear anyway in the image, because sometimes
> >>the dependency information in the packages are not complete nor correct.
> >>
> >>  * Some removed packages will break the build or the runtime, even
> >>though the dependencies say it should be ok. Users should be encouraged
> >>to test their changes early and often, and we may want to help save their
> >>bacon with checkpoints (based on the last successful
> >> build?) or multiple undo's so that they can back up to a working state
> >>rather than re-starting from scratch. Just saying.
> >>​​
> >>
> >>
> >>- David
> >>
> >>
> >>> -----Original Message-----
> >>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> >>> bounces@yoctoproject.org] On Behalf Of Michael Wood
> >>> Sent: Tuesday, June 23, 2015 9:32 AM
> >>> To: toaster@yoctoproject.org
> >>> Subject: Re: [Toaster] [RFC] Image customisation detailed design
> >>>
> >>> Thanks for the video Belén, Looks good.
> >>>
> >>> Couple of bits of feedback
> >>>
> >>> Creating an image recipe:
> >>>
> >>> I find the text in the modal too long, anything more than 2 sentences
> >>> and my attention span is over!
> >>>
> >>> I found it confusing that I entered a name and clicked create but have
> >>> not actually created anything, what about something like
> >>> suggestion1.png
> >>> (attached) this brings it more into line with import layer/create new
> >>> project/form based activity.
> >>>
> >>> Select a base image recipe:
> >>>
> >>> I was looking for a way to "de/re/select" an image, we don't quite have
> >>> the same concept here as the machines selection that I was expecting,
> >>> where you can always select regardless of whether it's already
> >>> selected.
> >>>
> >>> Add and delete packages:
> >>>
> >>> '.well' 1
> >>>
> >>> I was expecting the pencil to do the same as other pencils and activate
> >>> text input boxes. Obviously if you're on the Add/Delete packages page
> >>> you can't change the base image like that so maybe not having these
> >>> pencils would be better. I was also unsure as what the change
> >>> version/licence would do.
> >>>
> >>> '.well' 2
> >>>
> >>> If you've selected an image recipe and then remove the layer that
> >>> provides it... what happens?
> >>>
> >>> The Build Image recipe/ Download recipe file / Delete image recipe
> >>> buttons are somewhat easy to miss, they look a bit like progress
> >>> buttons
> >>> or other tabs. I wonder if they would be better off in '.well' 1. The
> >>> Build button could be more noticeable.
> >>>
> >>> In general if you can avoid having data in a table that for each one
> >>> requires extra data looking up the tables will be much
> >>> faster/efficient.
> >>> For example we have the dependencies button with total size displayed.
> >>> It should be really quick to count the number of dependences, but much
> >>> slower if we also have to retrieve the objects to get the data in them,
> >>> such as "name" and "size".  If we can do that by making it "on demand"
> >>> that's much better, e.g. you click the button and it fetches this extra
> >>> data.
> >>>
> >>> Thanks,
> >>>
> >>> Michael
> >>>
> >>>
> >>>
> >>> On 12/06/15 14:40, Barros Pena, Belen wrote:
> >>> > As I mentioned in the Toaster weekly meeting last Wednesday, I've
> >>> recorded
> >>> > a (not so short, sorry) video showing a much more detailed design for
> >>> the
> >>> > image customisation feature. The video is here
> >>> >
> >>> > 
> >>https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
> >><https://wiki.yoctoproject.org/wiki/images/a/a1/Image->
> >>> customisation.webm
> >>> >
> >>> > Everything that I show in the video is now available in the design
> >>> > prototype at
> >>> >
> >>> > https://yoctoproject.org/toaster
> >>> >
> >>> >
> >>> > Just in case you want to follow along ;)
> >>> >
> >>> > I think the design addresses pretty much all the feedback the Toaster
> >>> > contributors have provided so far (listed below). The only items not
> >>> > addressed are 1 (because it would require us to rethink Toaster as a
> >>> tool
> >>> > for absolute beginners and would impose a very specific workflow) and
> >>> 8
> >>> > (because I haven't had time to think about how we can do this, but we
> >>> can
> >>> > definitely come back to it).
> >>> >
> >>> > Please send any comments and new feedback to the mailing list so that
> >>> > Tiago can collect it and we can address it.
> >>> >
> >>> > This is the feedback we have received so far:
> >>> >
> >>> > 1. Should this kind of linear process be the main Toaster workflow,
> >>> > instead of the non-linear one currently provided by the existing
> >>> project
> >>> > page?
> >>> >
> >>> > 2. Size is project configuration dependent, so all size information
> >>> is a
> >>> > guess, an approximation. We should probably still show it, but the
> >>> > interface needs to present it as such (we need to make sure we don't
> >>> > present it as it was 100% accurate information). The same for
> >>> dependencies.
> >>> >
> >>> > 3. We need to create states for how the tables will look like when
> >>> certain
> >>> > information is missing (number of packages, sizes, etc)
> >>> >
> >>> > 4. We need to refine the recipe presentation in the workflow
> >>> >
> >>> > 5. We need to work on the way we present the actions. Do we really
> >>> need
> >>> > all the ones we have right now?
> >>> >
> >>> > 6. Replace the builds tab with a less prominent way of accessing
> >>> build
> >>> > information for the custom image recipe.
> >>> >
> >>> > 7. Provide a way to reenter the image customisation process from the
> >>> build
> >>> > results
> >>> >
> >>> > 8. Provide a way to 'select all' packages returned by a search
> >>> >
> >>> > 9. Do we need the reverse dependencies information in the packages
> >>> table?
> >>> >
> >>> > 10. Can we add the package size to the visible dependencies
> >>> information in
> >>> > the packages table?
> >>> >
> >>> > 11. The workflow is still too complex: too many concepts exposed
> >>> > (packages, layers, recipes). Should we just require people to build
> >>> the
> >>> > image they want to customise instead?
> >>> >
> >>> > Cheers
> >>> >
> >>> > Belén
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>
> >>
> >>
> >>--
> >>_______________________________________________
> >>toaster mailing list
> >>toaster@yoctoproject.org
> >>https://lists.yoctoproject.org/listinfo/toaster
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>-- 
> >>Alex Damian
> >>Yocto Project
> >>
> >>SSG / OTC 
> >>
> >>
> >>
> >>
> >
> >-- 
> >_______________________________________________
> >toaster mailing list
> >toaster@yoctoproject.org
> >https://lists.yoctoproject.org/listinfo/toaster
> 
> -- 
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster

-- 
--
Regards,
Ed

Re: [RFC] Image customisation detailed design

[Barros Pena, Belen]

On 09/07/2015 12:25, "Ed Bartosh" <ed.bartosh@linux.intel.com> wrote:

>Hi Belen,
>
>Sorry for the late feedback.

It's not late at all. Thanks for taking the time to give feedback :)

>
>Thank you for the nice and clear explanations and the video. It helped
>me a lot to understand UI design of the image customization.
>Despite my notices below I like the UI and overall concept. It
>looks much cleaner than before. Thank you.
>
>I decided to send my feedback to the mailing list as I don't have account
>on Yocto wiki yet.
>
>MICHAEL: I found it confusing that I entered a name and clicked create
>but have not actually created anything
>BELEN: mmm, this one is interesting. What makes you think that you have
>not created anything?
>ED: I agree with MICHAEL. This step doesn't create anything, but the
>name. Can we make choosing base image as a mandatory step or merge it
>with naming somehow?

Oh, all right. I guess I lose 2-1 ;) I'll try to work something out.

>
>ALEX: When configuring an image, I would suggest dropping the "Base
>image recipe" concept, because we can't follow on updates from the base
>image recipe after the custom recipe was created, and this will confuse
>the user.
>BELEN: and what do users do instead? Do they start they custom image
>recipes from a blank slate? That will most likely result in an image
>that doesn't build. Do you have an alternative starting point in mind?
>ALEX: The users would start from an already existing image, as they do
>now. What I'm suggesting is dropping the tab of possible base images,
>and the ability to change the base image for a custom image once the
>custom image recipe is created. This is the same point as below, just
>pointing to the tab.

My question would be then: what if I select the wrong base image? Or I
find at a later stage that a different base image would be a better
starting point? 

>ED: This would make sense to do as we're not tracking relationship
>between base and custom image after creation of custom image.

Somehow it does make sense to me too. My main concern is the question I
posed above. 

>People may get a wrong idea of tracking changes of base image in
>customized image if we keep showing base image name. It should be made
>clear that we're using base image only for fetching list of packages
>when we create custom image. Creation of custom image can be done
>similar to custimizing file in editor using 'Save as'. Users have to
>pick up base file and have to save it with the new name if they want
>to make a customizable copy of it. After that relationship between
>base file and custom one is lost. Can we do something similar?

My concern in this case is how do we provide users enough information
about the base image recipes *before* they select them. With a file, which
is the pattern you suggest we follow, you can open the file and look at
its contents at your heart's content. Then, whenever you have concluded
that you want to base your work on that file, you can start the 'save as'
process from it. We would need to do something equivalent in Toaster,
specially because you are asking above that once the selection has been
made, you cannot change it (which I still think is a bit unforgiving:
"sorry, you have made your choice. If you made the wrong one, well, live
with it" kind of approach. I tend not to like that sort of thing: I rather
be forgiving and give users the chance to change their mind about things).

I will look into this in any case, and see what could be done.

>
>MICHAEL: In general if you can avoid having data in a table that for
>each one requires extra data looking up the tables will be much
>faster/efficient. For example we have the dependencies button with total
>size displayed. It should be really quick to count the number of
>dependences, but much slower if we also have to retrieve the objects to
>get the data in them, such as "name" and "size". If we can do that by
>making it "on demand" that's much better, e.g. you click the button and
>it fetches this extra data.
>BELEN: this was my initial approach. From the UI perspective, it is also
>tidier. Then Ed asked to see this information without having to click,
>and I decided to give it a try to see how it would look like. I agree it
>is better to present it when you select a certain dependency, so I will
>revert to that. Sorry Ed :/
>ED: I tend to disagree with this. Size of the components is very
>important information when choosing base image. I agree that it should
>not be shown in the table as it'd slow UI down. However, this
>information is only shown when user presses the button with the number of
>dependencies.

Yes, that's exactly the plan. The table will show the number of
dependencies. When you click on that number, you will see the size (per
dependency and total).

>
>DAVID: How does this interface deal with "package groups"? People will
>ask.
>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-
>extend-customimage-customtasks
>BELEN: I'm afraid it doesn't. We know that at some point we'll need to
>distinguish package groups from other recipes, and break them up, i.e.
>allow people to remove packages from package groups. But during the high
>level design discussions we came to the conclusion that it would be too
>hard to do in version 1 - see page 11 of the initial design document
>https://wiki.yoctoproject.org/wiki/images/3/31/Image_customisation_in_Toas
>ter.pdf
>ED: Looking at existing image recipes I see "IMAGE_FEATURES +=" lines
>almost
>in all of them. This makes me think that most of the time images are
>customized by adding feature/groups. I think David is right here -
>people will definitely ask for this. It's just much more convenient,
>faster and understandable to deal with well defined components than with
>packages. For example IMAGE_FEATURES += "splash ssh-server-openssh
>hwcodecs
>package-management" is quite straightforward and clear to me. It would
>require user to pick up 4 groups from the list of groups with clear
>names. However, it's much harder to say how many and which packages to
>pick up to add this functionality to the image. I'm afraid without
>introducing groups we'll make image customization different from how
>it's done in real life and much harder that it should be.

Right: I didn't explain this very well. Toaster will show package groups,
and you will be able to add them and remove them like any other package.
What we will not show at this point is the content of the package groups
(i.e. which packages the package group installs).

>
>Additional questions:
>
>Adding / removing layers: Would it make sense to not allow users to
>remove layers if custom images use recipes from them?

I don't think we can do this. It would effectively mean stopping users
from deleting layers from a project until they delete the custom image
that it's causing the issue.

>Or at least
>notify user which recipes from the layer are used in custom images?

You can remove layers from several places: the configuration page, the all
compatible layers page, and now the image customisation pages. If we were
to warn users that a custom image of theirs is using recipes from the
layer they are removing, we would need to show the warning in all three
places.
 
My question is: can we even know this, I.e. Which recipes required to
build a certain custom image are provided by layer x? What if we are
dealign with imported layers that have never been built?

>
>There are a lot of variables available for tweaking
>in image recipesi: SUMMARY, DESCRIPTION, IMAGE_FSTYPES, etc.
>Are we going to allow changing them or allow editing recipes for custom
>images?

No plans to do this for the moment. Things like SUMMARY, DESCRIPTION and
SECTION we can expose via the right hand column of the image recipe
details page and allow users to set / edit. But I wouldn't go much farther
than this for the time being; I don't think we want to turn package
customisation into a full-blown recipe writing tool.

>
>Current set of image recipes uses single and multiple inheritance of
>other image recipes. Are we going to show inheritance tree and allow
>inheritance in custom recipes?

Uff, I am going to answer "I don't think so", but I suspect I am might be
missing some information. What I can tell you is what came out of our
initial design workshop (as documented in
https://wiki.yoctoproject.org/wiki/File:Image_customisation_in_Toaster.pdf,
 see pages 9 and 10):

"We discussed removing any reference to the image recipe selected as the
starting point after selection takes place. However, Paul Eggleton has
brought up that image recipes might include certain options beyond the
package list that users or vendors might be keen on keeping. This means
that there are 2 possible ways of creating the custom image recipes:

								1. By inheriting the starting point image recipe, and keeping
those extra options

								2. By not inheriting the starting point image recipe

In general, Yocto Project's core images will use the option 2, but this is
potentially something we could turn into an option users could select.
Although we should proceed with caution and provide a sane default, since
we cannot assume users will know or understand the difference between
both, and we are not planning to expose those "options" that will be kept
by inheriting the starting point image recipe."

Does the above answer your last question?

Cheers

Belén


>
>Regards,
>Ed
>
>On Fri, Jul 03, 2015 at 03:42:58PM +0000, Barros Pena, Belen wrote:
>> I finally had a chance to work through your feedback for the image
>> customisation design. I've grouped it into categories and replied to
>>each
>> of the comments. It is long, so I've transferred it to a wiki page
>> 
>> https://wiki.yoctoproject.org/wiki/Design_feedback
>> 
>> Search in page for your names if you want to see the answers to the
>>issues
>> you raised. Edit the page if you want to reply to any of them, or reply
>> here (whichever is easier for you).
>> 
>> There a few design ARs coming out of it all. The list is in
>> 
>> https://wiki.yoctoproject.org/wiki/Design_feedback#Design_ARs
>> 
>> I will be working through those next week.
>> 
>> Thanks all for your design review!
>> 
>> Belén
>>  
>> 
>> On 30/06/2015 13:58, "Barros Pena, Belen" <belen.barros.pena@intel.com>
>> wrote:
>> 
>> >Thanks all for taking the time to look at the design and provide
>>feedback!
>> >
>> >I need some time to digest your comments: hopefully we can discuss
>>during
>> >the Toaster meeting either this or next week.
>> >
>> >Cheers
>> >
>> >Belén
>> >
>> >On 26/06/2015 09:31, "Damian, Alexandru" <alexandru.damian@intel.com>
>> >wrote:
>> >
>> >>Hi,
>> >>
>> >>
>> >>Thanks for putting all this together - very informative and very
>>detailed
>> >>mockups. This gave me a great opportunity to review and take in the
>> >>interface over the last couple of days, and I thought
>> >> quite a bit about how it works.
>> >>
>> >>
>> >>I'm thinking this over from a bit of a different perspective - please
>> >>bear with the consistent comments below. The way the interface is
>> >>designed now is - select an image and modify it. This works
>> >> beautifully if you're pretty sure about what's in a specified image,
>>and
>> >>how you want to modify it. The way I'm seeing it is a bit different -
>>I
>> >>want to see what would be installed to the image, and modify the list
>>of
>> >>packages that are there. The difference
>> >> is a bit subtle, but it goes more on the discoverability/exploratory
>> >>side, and less on - just add and remove a couple of packages that I
>>know
>> >>that are there.
>> >>
>> >>
>> >>I have some comments of my own, and some replies to the comments
>>below.
>> >>
>> >>
>> >>
>> >>
>> >>1). I think it should be easy to build your own recipes in the
>> >>Configuration page. The text entry with the build button should be no
>> >>longer the primary means of starting a build, now that we can
>> >> configure the build itself.
>> >>
>> >>
>> >>I would suggest adding a "My image recipes" box in the style of "Most
>> >>build recipes" in the Configuration, with two big buttons : "Build
>> >>selected" and "New image recipe".
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>2). For a new user, it's not obvious how to start configuring the
>>image
>> >>contents, in the sense that "My image recipes" isn't the most obvious
>> >>place one would start to configure a build, which
>> >> is why people actually look for into Toaster.
>> >>
>> >>
>> >>I would suggest making "Type the target you want to build" and Build
>> >>button in a section similar to, and on top of the "Latest builds"
>> >>section. And add, in that section, in the project page, a
>> >> bit link "Configure the image contents".
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>3). Please drop the "New build" button. That button is a stop-gap
>>measure
>> >>to launching build commands, but now we're not simply issue-ing build
>> >>commands, we are actually configuring the build.
>> >> Even if you are an experienced user, it's opaque form - small and
>>with
>> >>very little information - makes it difficult to use.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>4). It seems a bit strange that I can navigate to most of the Project
>> >>options via the left hand menu, but not to image recipes. The
>> >>user-defined image recipes are Project-specific, and I think
>> >> they are at the same level with the "Image recipes" and "Software
>> >>recipes", but in the "CONFIGURATION" category.
>> >>
>> >>
>> >>I don't think that having a duplicate link as a tab is a problem, but
>>I
>> >>get frustrated by the disappearance of the left-hand-menu in the My
>>Image
>> >>Recipes. BTW, thinking of the naming, I would
>> >> suggest "Custom recipes", because it's not clear from the links that
>>I
>> >>can actually configure something there.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>5). When configuring an image, I would suggest dropping the "Base
>>image
>> >>recipe" concept, because we can't follow on updates from the base
>>image
>> >>recipe after the custom recipe was created, and
>> >> this will confuse the user.
>> >>
>> >>
>> >>Also, the tab with the Base image recipe in My Image details, allowing
>> >>the user to change the base image for a recipe, should be taken out,
>> >>since we cannot change the base image recipe after the
>> >> initial selection.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>6). The "Add A Layer" panel on the right hand side, I would've
>>expected
>> >>it to be a pop-up like in the configuration page, not take me to the
>> >>Compatible layers. It completely takes me out of the
>> >> context of what I was doing - I want to customize a image for
>>MinnowMax,
>> >>I want to add minnowmax and be done, not go to a different page, and
>>then
>> >>have no idea how to return in a single click.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>7). I subscribe to David's view that the popups are annoying and
>> >>unnecessary. I would suggest using box alerts as they are currently
>> >>implemented, to avoid obscuring the screen, and divert user's
>> >> attention. The feedback for immediate actions should not be in your
>> >>face. Ditto for the "data loading" spinner, let's make it a bit more
>> >>obscure. 
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>8). How do I know what's in my image in at a certain moment ? It
>>would be
>> >>great if I could have two tables in the image customization page - the
>> >>current contents of the image, and the packages
>> >> that are available. When selecting/removing a package (maybe we
>>should
>> >>change the terminology from Add/Delete?), a package would disappear
>>from
>> >>a list and appear in the second one. Also, when deleting / adding a
>>layer
>> >>in-page, the recipes available would just
>> >> appear/disappear from the "available recipes" table.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>9). In the "My image recipe", I am not sure why the primary actions
>>that
>> >>you can take on the recipe (Build, Download, Delete) are tucked away
>>in
>> >>the right hand side, when my focus is on the left
>> >> hand side, where I get drawn to the image name. Maybe we can move the
>> >>buttons, make them bigger, as to be clear they are the primary action
>>you
>> >>do with a customized image ?
>> >>
>> >>
>> >>
>> >>
>> >>Cheers,
>> >>Alex
>> >>
>> >>
>> >>
>> >>
>> >>On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David
>> >><david.reyna@windriver.com> wrote:
>> >>
>> >>Hi Belén,
>> >>
>> >>I also appreciate the video and sample Toaster pages!
>> >>
>> >>Here are my comments, in addition to Michael's.
>> >>
>> >>1) Can we add a filter so that we can show just the packages that we
>>can
>> >>delete?
>> >>
>> >>
>> >>
>> >>
>> >>​I suggested to have two tables - one with what's in the image, and
>>one
>> >>with what's available. I think this would cover the use case you have
>>in
>> >>mind.
>> >>
>> >>​
>> >> 
>> >>
>> >>
>> >>The use case is trimming the image, where we want the 100 packages
>>that
>> >>we wish to examine for removal not to be lost in the possible 1000's
>> >>packages that are available to add.
>> >>
>> >>2) I will admit that I was thrown by the new status pop-up, because
>>not
>> >>only does it cover things up on my page, I also generally associate
>>them
>> >>with spam and ad-ware.
>> >>
>> >>I understand your use for showing an action in progress, but we
>>already
>> >>had a metaphor for that in the progress/status bars inserted (when
>> >>applicable) at the top of the page. Why a new metaphor? What does it
>>add
>> >>that the regular model does not? I know that
>> >> it does stay visible while you for example scroll, but is that a hard
>> >>requirement?
>> >>
>> >>I also do not understand the dangling part, where I have to manual
>>cancel
>> >>it to make it go away. For example, I understand for example its use
>>in
>> >>the add layer parsing progress, but when it is done and says "Layer
>> >>Information updated" why do I have to manually
>> >> kill it? Could it at least go away on its own after a moment, and let
>> >>that be the clue that the process completed?
>> >>
>> >>The "Undo" feature though is nice!
>> >>
>> >>
>> >>
>> >>
>> >>​I'm not sure what the Undo feature is ? Can you give me a bit more
>> >>details ?
>> >>
>> >>​
>> >> 
>> >>
>> >>
>> >>3) The new page can add layers in place which is nice, and I see how
>>you
>> >>can use it to parse and show that layer's package count. However, it
>> >>appears that if I change my mind about the layer I have to go out to
>>the
>> >>layer page to remove it? Could perhaps the
>> >> "undo" feature also be made available here? Or a layer delete icon?
>> >>
>> >>Speaking of layer parsing, don't we already have an idea of the
>>package
>> >>count per layer from the "all packages" table?
>> >>
>> >>4) How does this interface deal with "package groups"? People will
>>ask.
>> >>
>> 
>>>>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpo
>>>>ky
>> >>-
>> >>extend-customimage-customtasks
>> >>
>> >>
>> >>5) Concerns about package removal
>> >>
>> >>Adding packages is easy, but we (WR) have found that removing them is
>> >>weirdly hard. I am very curious how the backend package
>>removal/exclusion
>> >>is being done, and who is doing it. In any case, we should have
>> >>disclaimers in place.
>> >>
>> >>
>> >>
>> >>
>> >>​This is a limitation of the way metadata is structured and tested.
>>Th​e
>> >>YP developers often miss correct dependency linking because the actual
>> >>dependencies for a package (e.g.
>> >> installed libraries) were already satisfied by another chain, so they
>> >>miss specifying the dependency in the metadata.
>> >>
>> >>
>> >>
>> >>
>> >>This problem will be re-occuring during Toaster use, and until we
>>clean
>> >>up the dependencies metadata, we need to tell the users exactly what's
>> >>going on - and enable them to timely
>> >> submit error reports about the invalid metadata. This is the only
>>way we
>> >>can actually clean everything up.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>  * Some removed packages appear anyway in the image, because
>>sometimes
>> >>the dependency information in the packages are not complete nor
>>correct.
>> >>
>> >>  * Some removed packages will break the build or the runtime, even
>> >>though the dependencies say it should be ok. Users should be
>>encouraged
>> >>to test their changes early and often, and we may want to help save
>>their
>> >>bacon with checkpoints (based on the last successful
>> >> build?) or multiple undo's so that they can back up to a working
>>state
>> >>rather than re-starting from scratch. Just saying.
>> >>​​
>> >>
>> >>
>> >>- David
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
>> >>> bounces@yoctoproject.org] On Behalf Of Michael Wood
>> >>> Sent: Tuesday, June 23, 2015 9:32 AM
>> >>> To: toaster@yoctoproject.org
>> >>> Subject: Re: [Toaster] [RFC] Image customisation detailed design
>> >>>
>> >>> Thanks for the video Belén, Looks good.
>> >>>
>> >>> Couple of bits of feedback
>> >>>
>> >>> Creating an image recipe:
>> >>>
>> >>> I find the text in the modal too long, anything more than 2
>>sentences
>> >>> and my attention span is over!
>> >>>
>> >>> I found it confusing that I entered a name and clicked create but
>>have
>> >>> not actually created anything, what about something like
>> >>> suggestion1.png
>> >>> (attached) this brings it more into line with import layer/create
>>new
>> >>> project/form based activity.
>> >>>
>> >>> Select a base image recipe:
>> >>>
>> >>> I was looking for a way to "de/re/select" an image, we don't quite
>>have
>> >>> the same concept here as the machines selection that I was
>>expecting,
>> >>> where you can always select regardless of whether it's already
>> >>> selected.
>> >>>
>> >>> Add and delete packages:
>> >>>
>> >>> '.well' 1
>> >>>
>> >>> I was expecting the pencil to do the same as other pencils and
>>activate
>> >>> text input boxes. Obviously if you're on the Add/Delete packages
>>page
>> >>> you can't change the base image like that so maybe not having these
>> >>> pencils would be better. I was also unsure as what the change
>> >>> version/licence would do.
>> >>>
>> >>> '.well' 2
>> >>>
>> >>> If you've selected an image recipe and then remove the layer that
>> >>> provides it... what happens?
>> >>>
>> >>> The Build Image recipe/ Download recipe file / Delete image recipe
>> >>> buttons are somewhat easy to miss, they look a bit like progress
>> >>> buttons
>> >>> or other tabs. I wonder if they would be better off in '.well' 1.
>>The
>> >>> Build button could be more noticeable.
>> >>>
>> >>> In general if you can avoid having data in a table that for each one
>> >>> requires extra data looking up the tables will be much
>> >>> faster/efficient.
>> >>> For example we have the dependencies button with total size
>>displayed.
>> >>> It should be really quick to count the number of dependences, but
>>much
>> >>> slower if we also have to retrieve the objects to get the data in
>>them,
>> >>> such as "name" and "size".  If we can do that by making it "on
>>demand"
>> >>> that's much better, e.g. you click the button and it fetches this
>>extra
>> >>> data.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Michael
>> >>>
>> >>>
>> >>>
>> >>> On 12/06/15 14:40, Barros Pena, Belen wrote:
>> >>> > As I mentioned in the Toaster weekly meeting last Wednesday, I've
>> >>> recorded
>> >>> > a (not so short, sorry) video showing a much more detailed design
>>for
>> >>> the
>> >>> > image customisation feature. The video is here
>> >>> >
>> >>> > 
>> >>https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
>> >><https://wiki.yoctoproject.org/wiki/images/a/a1/Image->
>> >>> customisation.webm
>> >>> >
>> >>> > Everything that I show in the video is now available in the design
>> >>> > prototype at
>> >>> >
>> >>> > https://yoctoproject.org/toaster
>> >>> >
>> >>> >
>> >>> > Just in case you want to follow along ;)
>> >>> >
>> >>> > I think the design addresses pretty much all the feedback the
>>Toaster
>> >>> > contributors have provided so far (listed below). The only items
>>not
>> >>> > addressed are 1 (because it would require us to rethink Toaster
>>as a
>> >>> tool
>> >>> > for absolute beginners and would impose a very specific workflow)
>>and
>> >>> 8
>> >>> > (because I haven't had time to think about how we can do this,
>>but we
>> >>> can
>> >>> > definitely come back to it).
>> >>> >
>> >>> > Please send any comments and new feedback to the mailing list so
>>that
>> >>> > Tiago can collect it and we can address it.
>> >>> >
>> >>> > This is the feedback we have received so far:
>> >>> >
>> >>> > 1. Should this kind of linear process be the main Toaster
>>workflow,
>> >>> > instead of the non-linear one currently provided by the existing
>> >>> project
>> >>> > page?
>> >>> >
>> >>> > 2. Size is project configuration dependent, so all size
>>information
>> >>> is a
>> >>> > guess, an approximation. We should probably still show it, but the
>> >>> > interface needs to present it as such (we need to make sure we
>>don't
>> >>> > present it as it was 100% accurate information). The same for
>> >>> dependencies.
>> >>> >
>> >>> > 3. We need to create states for how the tables will look like when
>> >>> certain
>> >>> > information is missing (number of packages, sizes, etc)
>> >>> >
>> >>> > 4. We need to refine the recipe presentation in the workflow
>> >>> >
>> >>> > 5. We need to work on the way we present the actions. Do we really
>> >>> need
>> >>> > all the ones we have right now?
>> >>> >
>> >>> > 6. Replace the builds tab with a less prominent way of accessing
>> >>> build
>> >>> > information for the custom image recipe.
>> >>> >
>> >>> > 7. Provide a way to reenter the image customisation process from
>>the
>> >>> build
>> >>> > results
>> >>> >
>> >>> > 8. Provide a way to 'select all' packages returned by a search
>> >>> >
>> >>> > 9. Do we need the reverse dependencies information in the packages
>> >>> table?
>> >>> >
>> >>> > 10. Can we add the package size to the visible dependencies
>> >>> information in
>> >>> > the packages table?
>> >>> >
>> >>> > 11. The workflow is still too complex: too many concepts exposed
>> >>> > (packages, layers, recipes). Should we just require people to
>>build
>> >>> the
>> >>> > image they want to customise instead?
>> >>> >
>> >>> > Cheers
>> >>> >
>> >>> > Belén
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >>
>> >>--
>> >>_______________________________________________
>> >>toaster mailing list
>> >>toaster@yoctoproject.org
>> >>https://lists.yoctoproject.org/listinfo/toaster
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>-- 
>> >>Alex Damian
>> >>Yocto Project
>> >>
>> >>SSG / OTC 
>> >>
>> >>
>> >>
>> >>
>> >
>> >-- 
>> >_______________________________________________
>> >toaster mailing list
>> >toaster@yoctoproject.org
>> >https://lists.yoctoproject.org/listinfo/toaster
>> 
>> -- 
>> _______________________________________________
>> toaster mailing list
>> toaster@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster
>
>-- 
>--
>Regards,
>Ed

Re: [RFC] Image customisation detailed design

[Ed Bartosh]

Hi Belen,
> >
> >MICHAEL: I found it confusing that I entered a name and clicked create
> >but have not actually created anything
> >BELEN: mmm, this one is interesting. What makes you think that you have
> >not created anything?
> >ED: I agree with MICHAEL. This step doesn't create anything, but the
> >name. Can we make choosing base image as a mandatory step or merge it
> >with naming somehow?
> 
> Oh, all right. I guess I lose 2-1 ;) I'll try to work something out.
> 
> >
> >ALEX: When configuring an image, I would suggest dropping the "Base
> >image recipe" concept, because we can't follow on updates from the base
> >image recipe after the custom recipe was created, and this will confuse
> >the user.
> >BELEN: and what do users do instead? Do they start they custom image
> >recipes from a blank slate? That will most likely result in an image
> >that doesn't build. Do you have an alternative starting point in mind?
> >ALEX: The users would start from an already existing image, as they do
> >now. What I'm suggesting is dropping the tab of possible base images,
> >and the ability to change the base image for a custom image once the
> >custom image recipe is created. This is the same point as below, just
> >pointing to the tab.
> 
> My question would be then: what if I select the wrong base image? Or I
> find at a later stage that a different base image would be a better
> starting point? 
> 
What about allowing user to change base image only until custom recipe
is modified?

> >ED: This would make sense to do as we're not tracking relationship
> >between base and custom image after creation of custom image.
> 
> Somehow it does make sense to me too. My main concern is the question I
> posed above. 
> 
Your concern makes sense to me. However, if user adds or removes
packages and then changes base image it could become not possible
to apply previous changes. To handle such a cases UI will
become more complex, which is generally bad thing from my point of view.

> >People may get a wrong idea of tracking changes of base image in
> >customized image if we keep showing base image name. It should be made
> >clear that we're using base image only for fetching list of packages
> >when we create custom image. Creation of custom image can be done
> >similar to custimizing file in editor using 'Save as'. Users have to
> >pick up base file and have to save it with the new name if they want
> >to make a customizable copy of it. After that relationship between
> >base file and custom one is lost. Can we do something similar?
> 
> My concern in this case is how do we provide users enough information
> about the base image recipes *before* they select them.
Now I start getting your idea and I agree with you. We need to give user
possibility to see the result, i.e. to build an image. If it doesn't
look good for some reason user should be able to change base image.
In this case we should clearly show the user a status of previously made
changes - a delta. If delta is not appliable to the new base image it
should be clearly shown in UI. However, it would make UI more complex.

> With a file, which
> is the pattern you suggest we follow, you can open the file and look at
> its contents at your heart's content. Then, whenever you have concluded
> that you want to base your work on that file, you can start the 'save as'
> process from it. We would need to do something equivalent in Toaster,
> specially because you are asking above that once the selection has been
> made, you cannot change it (which I still think is a bit unforgiving:
> "sorry, you have made your choice. If you made the wrong one, well, live
> with it" kind of approach. I tend not to like that sort of thing: I rather
> be forgiving and give users the chance to change their mind about things).
> 
> I will look into this in any case, and see what could be done.
> 
> >
> >MICHAEL: In general if you can avoid having data in a table that for
> >each one requires extra data looking up the tables will be much
> >faster/efficient. For example we have the dependencies button with total
> >size displayed. It should be really quick to count the number of
> >dependences, but much slower if we also have to retrieve the objects to
> >get the data in them, such as "name" and "size". If we can do that by
> >making it "on demand" that's much better, e.g. you click the button and
> >it fetches this extra data.
> >BELEN: this was my initial approach. From the UI perspective, it is also
> >tidier. Then Ed asked to see this information without having to click,
> >and I decided to give it a try to see how it would look like. I agree it
> >is better to present it when you select a certain dependency, so I will
> >revert to that. Sorry Ed :/
> >ED: I tend to disagree with this. Size of the components is very
> >important information when choosing base image. I agree that it should
> >not be shown in the table as it'd slow UI down. However, this
> >information is only shown when user presses the button with the number of
> >dependencies.
> 
> Yes, that's exactly the plan. The table will show the number of
> dependencies. When you click on that number, you will see the size (per
> dependency and total).
> 
I probably missed that, sorry. I think I saw a button with the amount of
deps on it, so I thought Michael was against that.

> >
> >DAVID: How does this interface deal with "package groups"? People will
> >ask.
> >http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-
> >extend-customimage-customtasks
> >BELEN: I'm afraid it doesn't. We know that at some point we'll need to
> >distinguish package groups from other recipes, and break them up, i.e.
> >allow people to remove packages from package groups. But during the high
> >level design discussions we came to the conclusion that it would be too
> >hard to do in version 1 - see page 11 of the initial design document
> >https://wiki.yoctoproject.org/wiki/images/3/31/Image_customisation_in_Toas
> >ter.pdf
> >ED: Looking at existing image recipes I see "IMAGE_FEATURES +=" lines
> >almost
> >in all of them. This makes me think that most of the time images are
> >customized by adding feature/groups. I think David is right here -
> >people will definitely ask for this. It's just much more convenient,
> >faster and understandable to deal with well defined components than with
> >packages. For example IMAGE_FEATURES += "splash ssh-server-openssh
> >hwcodecs
> >package-management" is quite straightforward and clear to me. It would
> >require user to pick up 4 groups from the list of groups with clear
> >names. However, it's much harder to say how many and which packages to
> >pick up to add this functionality to the image. I'm afraid without
> >introducing groups we'll make image customization different from how
> >it's done in real life and much harder that it should be.
> 
> Right: I didn't explain this very well. Toaster will show package groups,
> and you will be able to add them and remove them like any other package.
> What we will not show at this point is the content of the package groups
> (i.e. which packages the package group installs).
> 
Great! Thank you for the explanation.

> >
> >Additional questions:
> >
> >Adding / removing layers: Would it make sense to not allow users to
> >remove layers if custom images use recipes from them?
> 
> I don't think we can do this. It would effectively mean stopping users
> from deleting layers from a project until they delete the custom image
> that it's causing the issue.
> 
From other hand if we allow this it would mean that we're basically allowing
user to break custom images without knowing about this. We should at least
notify user about possible outcome.

> >Or at least
> >notify user which recipes from the layer are used in custom images?
> 
> You can remove layers from several places: the configuration page, the all
> compatible layers page, and now the image customisation pages. If we were
> to warn users that a custom image of theirs is using recipes from the
> layer they are removing, we would need to show the warning in all three
> places.
>  
> My question is: can we even know this, I.e. Which recipes required to
> build a certain custom image are provided by layer x? What if we are
> dealign with imported layers that have never been built?
>
I can only guess that bitbake has this information as it parses all
layers before the build.

> >
> >There are a lot of variables available for tweaking
> >in image recipesi: SUMMARY, DESCRIPTION, IMAGE_FSTYPES, etc.
> >Are we going to allow changing them or allow editing recipes for custom
> >images?
> 
> No plans to do this for the moment. Things like SUMMARY, DESCRIPTION and
> SECTION we can expose via the right hand column of the image recipe
> details page and allow users to set / edit. But I wouldn't go much farther
> than this for the time being; I don't think we want to turn package
> customisation into a full-blown recipe writing tool.
> 
I think allowing user to see and edit image recipe is not hard to
implement. We don't need anything fancy here. Just editable text
area with recipe in it would be enough. This would bring a lot of
flexibility to the process from my point of view.

It could be marked as an advanced feature
in UI if you think it's too dangerous for not experienced users.
I personally think it's not dangerous at all as the worst thing user can
do with it is to break image build, but this is easily doable by adding or
removing package or group too.

> >
> >Current set of image recipes uses single and multiple inheritance of
> >other image recipes. Are we going to show inheritance tree and allow
> >inheritance in custom recipes?
> 
> Uff, I am going to answer "I don't think so", but I suspect I am might be
> missing some information. What I can tell you is what came out of our
> initial design workshop (as documented in
> https://wiki.yoctoproject.org/wiki/File:Image_customisation_in_Toaster.pdf,
>  see pages 9 and 10):
> 
> "We discussed removing any reference to the image recipe selected as the
> starting point after selection takes place. However, Paul Eggleton has
> brought up that image recipes might include certain options beyond the
> package list that users or vendors might be keen on keeping. This means
> that there are 2 possible ways of creating the custom image recipes:
> 
> 								1. By inheriting the starting point image recipe, and keeping
> those extra options
> 
> 								2. By not inheriting the starting point image recipe
> 
> In general, Yocto Project's core images will use the option 2, but this is
> potentially something we could turn into an option users could select.
> Although we should proceed with caution and provide a sane default, since
> we cannot assume users will know or understand the difference between
> both, and we are not planning to expose those "options" that will be kept
> by inheriting the starting point image recipe."
> 
> Does the above answer your last question?
> 
I don't know :)
It may confirm your "I don't think so" answer.
I asked about this just out of curiosity, so any answer is ok for me.

> Cheers
> 
> Belén
> 
> 
> >
> >Regards,
> >Ed
> >
> >On Fri, Jul 03, 2015 at 03:42:58PM +0000, Barros Pena, Belen wrote:
> >> I finally had a chance to work through your feedback for the image
> >> customisation design. I've grouped it into categories and replied to
> >>each
> >> of the comments. It is long, so I've transferred it to a wiki page
> >> 
> >> https://wiki.yoctoproject.org/wiki/Design_feedback
> >> 
> >> Search in page for your names if you want to see the answers to the
> >>issues
> >> you raised. Edit the page if you want to reply to any of them, or reply
> >> here (whichever is easier for you).
> >> 
> >> There a few design ARs coming out of it all. The list is in
> >> 
> >> https://wiki.yoctoproject.org/wiki/Design_feedback#Design_ARs
> >> 
> >> I will be working through those next week.
> >> 
> >> Thanks all for your design review!
> >> 
> >> Belén
> >>  
> >> 
> >> On 30/06/2015 13:58, "Barros Pena, Belen" <belen.barros.pena@intel.com>
> >> wrote:
> >> 
> >> >Thanks all for taking the time to look at the design and provide
> >>feedback!
> >> >
> >> >I need some time to digest your comments: hopefully we can discuss
> >>during
> >> >the Toaster meeting either this or next week.
> >> >
> >> >Cheers
> >> >
> >> >Belén
> >> >
> >> >On 26/06/2015 09:31, "Damian, Alexandru" <alexandru.damian@intel.com>
> >> >wrote:
> >> >
> >> >>Hi,
> >> >>
> >> >>
> >> >>Thanks for putting all this together - very informative and very
> >>detailed
> >> >>mockups. This gave me a great opportunity to review and take in the
> >> >>interface over the last couple of days, and I thought
> >> >> quite a bit about how it works.
> >> >>
> >> >>
> >> >>I'm thinking this over from a bit of a different perspective - please
> >> >>bear with the consistent comments below. The way the interface is
> >> >>designed now is - select an image and modify it. This works
> >> >> beautifully if you're pretty sure about what's in a specified image,
> >>and
> >> >>how you want to modify it. The way I'm seeing it is a bit different -
> >>I
> >> >>want to see what would be installed to the image, and modify the list
> >>of
> >> >>packages that are there. The difference
> >> >> is a bit subtle, but it goes more on the discoverability/exploratory
> >> >>side, and less on - just add and remove a couple of packages that I
> >>know
> >> >>that are there.
> >> >>
> >> >>
> >> >>I have some comments of my own, and some replies to the comments
> >>below.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>1). I think it should be easy to build your own recipes in the
> >> >>Configuration page. The text entry with the build button should be no
> >> >>longer the primary means of starting a build, now that we can
> >> >> configure the build itself.
> >> >>
> >> >>
> >> >>I would suggest adding a "My image recipes" box in the style of "Most
> >> >>build recipes" in the Configuration, with two big buttons : "Build
> >> >>selected" and "New image recipe".
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>2). For a new user, it's not obvious how to start configuring the
> >>image
> >> >>contents, in the sense that "My image recipes" isn't the most obvious
> >> >>place one would start to configure a build, which
> >> >> is why people actually look for into Toaster.
> >> >>
> >> >>
> >> >>I would suggest making "Type the target you want to build" and Build
> >> >>button in a section similar to, and on top of the "Latest builds"
> >> >>section. And add, in that section, in the project page, a
> >> >> bit link "Configure the image contents".
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>3). Please drop the "New build" button. That button is a stop-gap
> >>measure
> >> >>to launching build commands, but now we're not simply issue-ing build
> >> >>commands, we are actually configuring the build.
> >> >> Even if you are an experienced user, it's opaque form - small and
> >>with
> >> >>very little information - makes it difficult to use.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>4). It seems a bit strange that I can navigate to most of the Project
> >> >>options via the left hand menu, but not to image recipes. The
> >> >>user-defined image recipes are Project-specific, and I think
> >> >> they are at the same level with the "Image recipes" and "Software
> >> >>recipes", but in the "CONFIGURATION" category.
> >> >>
> >> >>
> >> >>I don't think that having a duplicate link as a tab is a problem, but
> >>I
> >> >>get frustrated by the disappearance of the left-hand-menu in the My
> >>Image
> >> >>Recipes. BTW, thinking of the naming, I would
> >> >> suggest "Custom recipes", because it's not clear from the links that
> >>I
> >> >>can actually configure something there.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>5). When configuring an image, I would suggest dropping the "Base
> >>image
> >> >>recipe" concept, because we can't follow on updates from the base
> >>image
> >> >>recipe after the custom recipe was created, and
> >> >> this will confuse the user.
> >> >>
> >> >>
> >> >>Also, the tab with the Base image recipe in My Image details, allowing
> >> >>the user to change the base image for a recipe, should be taken out,
> >> >>since we cannot change the base image recipe after the
> >> >> initial selection.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>6). The "Add A Layer" panel on the right hand side, I would've
> >>expected
> >> >>it to be a pop-up like in the configuration page, not take me to the
> >> >>Compatible layers. It completely takes me out of the
> >> >> context of what I was doing - I want to customize a image for
> >>MinnowMax,
> >> >>I want to add minnowmax and be done, not go to a different page, and
> >>then
> >> >>have no idea how to return in a single click.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>7). I subscribe to David's view that the popups are annoying and
> >> >>unnecessary. I would suggest using box alerts as they are currently
> >> >>implemented, to avoid obscuring the screen, and divert user's
> >> >> attention. The feedback for immediate actions should not be in your
> >> >>face. Ditto for the "data loading" spinner, let's make it a bit more
> >> >>obscure. 
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>8). How do I know what's in my image in at a certain moment ? It
> >>would be
> >> >>great if I could have two tables in the image customization page - the
> >> >>current contents of the image, and the packages
> >> >> that are available. When selecting/removing a package (maybe we
> >>should
> >> >>change the terminology from Add/Delete?), a package would disappear
> >>from
> >> >>a list and appear in the second one. Also, when deleting / adding a
> >>layer
> >> >>in-page, the recipes available would just
> >> >> appear/disappear from the "available recipes" table.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>9). In the "My image recipe", I am not sure why the primary actions
> >>that
> >> >>you can take on the recipe (Build, Download, Delete) are tucked away
> >>in
> >> >>the right hand side, when my focus is on the left
> >> >> hand side, where I get drawn to the image name. Maybe we can move the
> >> >>buttons, make them bigger, as to be clear they are the primary action
> >>you
> >> >>do with a customized image ?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>Cheers,
> >> >>Alex
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David
> >> >><david.reyna@windriver.com> wrote:
> >> >>
> >> >>Hi Belén,
> >> >>
> >> >>I also appreciate the video and sample Toaster pages!
> >> >>
> >> >>Here are my comments, in addition to Michael's.
> >> >>
> >> >>1) Can we add a filter so that we can show just the packages that we
> >>can
> >> >>delete?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>​I suggested to have two tables - one with what's in the image, and
> >>one
> >> >>with what's available. I think this would cover the use case you have
> >>in
> >> >>mind.
> >> >>
> >> >>​
> >> >> 
> >> >>
> >> >>
> >> >>The use case is trimming the image, where we want the 100 packages
> >>that
> >> >>we wish to examine for removal not to be lost in the possible 1000's
> >> >>packages that are available to add.
> >> >>
> >> >>2) I will admit that I was thrown by the new status pop-up, because
> >>not
> >> >>only does it cover things up on my page, I also generally associate
> >>them
> >> >>with spam and ad-ware.
> >> >>
> >> >>I understand your use for showing an action in progress, but we
> >>already
> >> >>had a metaphor for that in the progress/status bars inserted (when
> >> >>applicable) at the top of the page. Why a new metaphor? What does it
> >>add
> >> >>that the regular model does not? I know that
> >> >> it does stay visible while you for example scroll, but is that a hard
> >> >>requirement?
> >> >>
> >> >>I also do not understand the dangling part, where I have to manual
> >>cancel
> >> >>it to make it go away. For example, I understand for example its use
> >>in
> >> >>the add layer parsing progress, but when it is done and says "Layer
> >> >>Information updated" why do I have to manually
> >> >> kill it? Could it at least go away on its own after a moment, and let
> >> >>that be the clue that the process completed?
> >> >>
> >> >>The "Undo" feature though is nice!
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>​I'm not sure what the Undo feature is ? Can you give me a bit more
> >> >>details ?
> >> >>
> >> >>​
> >> >> 
> >> >>
> >> >>
> >> >>3) The new page can add layers in place which is nice, and I see how
> >>you
> >> >>can use it to parse and show that layer's package count. However, it
> >> >>appears that if I change my mind about the layer I have to go out to
> >>the
> >> >>layer page to remove it? Could perhaps the
> >> >> "undo" feature also be made available here? Or a layer delete icon?
> >> >>
> >> >>Speaking of layer parsing, don't we already have an idea of the
> >>package
> >> >>count per layer from the "all packages" table?
> >> >>
> >> >>4) How does this interface deal with "package groups"? People will
> >>ask.
> >> >>
> >> 
> >>>>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpo
> >>>>ky
> >> >>-
> >> >>extend-customimage-customtasks
> >> >>
> >> >>
> >> >>5) Concerns about package removal
> >> >>
> >> >>Adding packages is easy, but we (WR) have found that removing them is
> >> >>weirdly hard. I am very curious how the backend package
> >>removal/exclusion
> >> >>is being done, and who is doing it. In any case, we should have
> >> >>disclaimers in place.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>​This is a limitation of the way metadata is structured and tested.
> >>Th​e
> >> >>YP developers often miss correct dependency linking because the actual
> >> >>dependencies for a package (e.g.
> >> >> installed libraries) were already satisfied by another chain, so they
> >> >>miss specifying the dependency in the metadata.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>This problem will be re-occuring during Toaster use, and until we
> >>clean
> >> >>up the dependencies metadata, we need to tell the users exactly what's
> >> >>going on - and enable them to timely
> >> >> submit error reports about the invalid metadata. This is the only
> >>way we
> >> >>can actually clean everything up.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>  * Some removed packages appear anyway in the image, because
> >>sometimes
> >> >>the dependency information in the packages are not complete nor
> >>correct.
> >> >>
> >> >>  * Some removed packages will break the build or the runtime, even
> >> >>though the dependencies say it should be ok. Users should be
> >>encouraged
> >> >>to test their changes early and often, and we may want to help save
> >>their
> >> >>bacon with checkpoints (based on the last successful
> >> >> build?) or multiple undo's so that they can back up to a working
> >>state
> >> >>rather than re-starting from scratch. Just saying.
> >> >>​​
> >> >>
> >> >>
> >> >>- David
> >> >>
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> >> >>> bounces@yoctoproject.org] On Behalf Of Michael Wood
> >> >>> Sent: Tuesday, June 23, 2015 9:32 AM
> >> >>> To: toaster@yoctoproject.org
> >> >>> Subject: Re: [Toaster] [RFC] Image customisation detailed design
> >> >>>
> >> >>> Thanks for the video Belén, Looks good.
> >> >>>
> >> >>> Couple of bits of feedback
> >> >>>
> >> >>> Creating an image recipe:
> >> >>>
> >> >>> I find the text in the modal too long, anything more than 2
> >>sentences
> >> >>> and my attention span is over!
> >> >>>
> >> >>> I found it confusing that I entered a name and clicked create but
> >>have
> >> >>> not actually created anything, what about something like
> >> >>> suggestion1.png
> >> >>> (attached) this brings it more into line with import layer/create
> >>new
> >> >>> project/form based activity.
> >> >>>
> >> >>> Select a base image recipe:
> >> >>>
> >> >>> I was looking for a way to "de/re/select" an image, we don't quite
> >>have
> >> >>> the same concept here as the machines selection that I was
> >>expecting,
> >> >>> where you can always select regardless of whether it's already
> >> >>> selected.
> >> >>>
> >> >>> Add and delete packages:
> >> >>>
> >> >>> '.well' 1
> >> >>>
> >> >>> I was expecting the pencil to do the same as other pencils and
> >>activate
> >> >>> text input boxes. Obviously if you're on the Add/Delete packages
> >>page
> >> >>> you can't change the base image like that so maybe not having these
> >> >>> pencils would be better. I was also unsure as what the change
> >> >>> version/licence would do.
> >> >>>
> >> >>> '.well' 2
> >> >>>
> >> >>> If you've selected an image recipe and then remove the layer that
> >> >>> provides it... what happens?
> >> >>>
> >> >>> The Build Image recipe/ Download recipe file / Delete image recipe
> >> >>> buttons are somewhat easy to miss, they look a bit like progress
> >> >>> buttons
> >> >>> or other tabs. I wonder if they would be better off in '.well' 1.
> >>The
> >> >>> Build button could be more noticeable.
> >> >>>
> >> >>> In general if you can avoid having data in a table that for each one
> >> >>> requires extra data looking up the tables will be much
> >> >>> faster/efficient.
> >> >>> For example we have the dependencies button with total size
> >>displayed.
> >> >>> It should be really quick to count the number of dependences, but
> >>much
> >> >>> slower if we also have to retrieve the objects to get the data in
> >>them,
> >> >>> such as "name" and "size".  If we can do that by making it "on
> >>demand"
> >> >>> that's much better, e.g. you click the button and it fetches this
> >>extra
> >> >>> data.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Michael
> >> >>>
> >> >>>
> >> >>>
> >> >>> On 12/06/15 14:40, Barros Pena, Belen wrote:
> >> >>> > As I mentioned in the Toaster weekly meeting last Wednesday, I've
> >> >>> recorded
> >> >>> > a (not so short, sorry) video showing a much more detailed design
> >>for
> >> >>> the
> >> >>> > image customisation feature. The video is here
> >> >>> >
> >> >>> > 
> >> >>https://wiki.yoctoproject.org/wiki/images/a/a1/Image-
> >> >><https://wiki.yoctoproject.org/wiki/images/a/a1/Image->
> >> >>> customisation.webm
> >> >>> >
> >> >>> > Everything that I show in the video is now available in the design
> >> >>> > prototype at
> >> >>> >
> >> >>> > https://yoctoproject.org/toaster
> >> >>> >
> >> >>> >
> >> >>> > Just in case you want to follow along ;)
> >> >>> >
> >> >>> > I think the design addresses pretty much all the feedback the
> >>Toaster
> >> >>> > contributors have provided so far (listed below). The only items
> >>not
> >> >>> > addressed are 1 (because it would require us to rethink Toaster
> >>as a
> >> >>> tool
> >> >>> > for absolute beginners and would impose a very specific workflow)
> >>and
> >> >>> 8
> >> >>> > (because I haven't had time to think about how we can do this,
> >>but we
> >> >>> can
> >> >>> > definitely come back to it).
> >> >>> >
> >> >>> > Please send any comments and new feedback to the mailing list so
> >>that
> >> >>> > Tiago can collect it and we can address it.
> >> >>> >
> >> >>> > This is the feedback we have received so far:
> >> >>> >
> >> >>> > 1. Should this kind of linear process be the main Toaster
> >>workflow,
> >> >>> > instead of the non-linear one currently provided by the existing
> >> >>> project
> >> >>> > page?
> >> >>> >
> >> >>> > 2. Size is project configuration dependent, so all size
> >>information
> >> >>> is a
> >> >>> > guess, an approximation. We should probably still show it, but the
> >> >>> > interface needs to present it as such (we need to make sure we
> >>don't
> >> >>> > present it as it was 100% accurate information). The same for
> >> >>> dependencies.
> >> >>> >
> >> >>> > 3. We need to create states for how the tables will look like when
> >> >>> certain
> >> >>> > information is missing (number of packages, sizes, etc)
> >> >>> >
> >> >>> > 4. We need to refine the recipe presentation in the workflow
> >> >>> >
> >> >>> > 5. We need to work on the way we present the actions. Do we really
> >> >>> need
> >> >>> > all the ones we have right now?
> >> >>> >
> >> >>> > 6. Replace the builds tab with a less prominent way of accessing
> >> >>> build
> >> >>> > information for the custom image recipe.
> >> >>> >
> >> >>> > 7. Provide a way to reenter the image customisation process from
> >>the
> >> >>> build
> >> >>> > results
> >> >>> >
> >> >>> > 8. Provide a way to 'select all' packages returned by a search
> >> >>> >
> >> >>> > 9. Do we need the reverse dependencies information in the packages
> >> >>> table?
> >> >>> >
> >> >>> > 10. Can we add the package size to the visible dependencies
> >> >>> information in
> >> >>> > the packages table?
> >> >>> >
> >> >>> > 11. The workflow is still too complex: too many concepts exposed
> >> >>> > (packages, layers, recipes). Should we just require people to
> >>build
> >> >>> the
> >> >>> > image they want to customise instead?
> >> >>> >
> >> >>> > Cheers
> >> >>> >
> >> >>> > Belén
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >>
> >> >>--
> >> >>_______________________________________________
> >> >>toaster mailing list
> >> >>toaster@yoctoproject.org
> >> >>https://lists.yoctoproject.org/listinfo/toaster
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>-- 
> >> >>Alex Damian
> >> >>Yocto Project
> >> >>
> >> >>SSG / OTC 
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >-- 
> >> >_______________________________________________
> >> >toaster mailing list
> >> >toaster@yoctoproject.org
> >> >https://lists.yoctoproject.org/listinfo/toaster
> >> 
> >> -- 
> >> _______________________________________________
> >> toaster mailing list
> >> toaster@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/toaster
> >
> >-- 
> >--
> >Regards,
> >Ed
> 

-- 
--
Regards,
Ed