[Toaster] [RFC] Image customisation detailed design (v2)

Barros Pena, Belen belen.barros.pena at intel.com
Fri Jul 17 05:29:49 PDT 2015 

So far I've heard from David, Ed, Paul, Alex and Michael. Thanks people
for taking the time to review the design and coming back to me.

* Ed has some questions (which I have answered below)
* Paul regrets the loss of the layer parsing functionality (but he is ok
with compromising for now)
* Michael doesn't like the wide buttons or the position of the 'new custom
image' option (we can definitely look into both)

But in general, everybody seems to agree this second version is better
than the first one, and it is something we can all agree on building as a
v1. I will start documenting the design and breaking it down into Bugzilla
features. 


If anybody else has comments / objections / questions, etc, please send
them quickly or we'll not be able to do anything about them.

Cheers

Belén

On 16/07/2015 10:36, "Ed Bartosh" <ed.bartosh at linux.intel.com> wrote:

>On Tue, Jul 14, 2015 at 09:50:22PM +0000, Barros Pena, Belen wrote:
>> After looking at the feedback I got about the image customisation
>>design,
>> I've created a second version, and then recoded another video:
>> 
>> 
>>https://wiki.yoctoproject.org/wiki/images/9/90/Image-customisation-v2.web
>>m
>> 
>> 
>> The video does not cover every single detail, but I hope it will give
>>you
>> an idea of the most important bits.
>> 
>> As you will see, the new design is quite different from the previous
>>one:
>> 
>> * Your image recipes are now called 'custom images'
>> * They no longer live in a separate section: they are listed with the
>>rest
>> of the project compatible metadata
>> * The first step when you create a custom image is no longer giving it a
>> name, but selecting the base image recipe
>> * Each base image recipe has now its own page, where you can check the
>> list of packages it installs (if known)
>> * Once you have selected a base image recipe, you can no longer change
>>it
>> * The parsing layers process is no longer there: you must now build the
>> image to get the package content if Toaster does not have the
>>information
>> 
>> I think the above addresses the main issues you raised in your comments
>> about the first design. It also seems to simplify things quite a bit,
>> which should be a good thing.
>> 
>> Let me know what you think.
>> 
>
>Thank you for the video!
>
>I like the design. It's simple and clear.
>
>Here are my notes and questions:
>
>1. One thing I didn't get is why it's not possible to add packages if
>image
>is not built? As far as I understood user should be able to add packages
>from other layers. I agree it's a bit tricky to add packages to the
>unknown set, but still.

I guess my main concern at that point is making the situation as clear as
possible. I worry that adding the ability to add packages to an
indeterminate set might somehow muddle things.

>
>2. Would it make sense to show only built images in the list of base
>images
>for customization?

That would effectively hide away all images from a new project. The
existing design exposes all existing images you can choose from by using
an interaction (the 2 step add-layer-then-do-something-else) that I've
seen working well when testing with users back in May. So I rather apply
the same principle since it is familiar from other areas of Toaster, and
it keeps images easily accessible instead of hiding them away.

>It would simplify UI even more. We are forcing user
>to build an image to be able to customize it. Why not go further and
>make the procedure even more simpler?
>
>3. What does it mean 'Package size'? Is it image size or something else?

I believe this will be the sum of the size of all packages installed by an
image, not the rootfs size. I think the problem with the rootfs size is
that it changes based on the image type, right? But I could be missing
something here. Is there any other measure we could / should use?

>
>PS: What about editing of .bb files?

Heh :) You are not the first one expressing an interest on this feature. I
guess I need to give you a bit of history to explain my position on this
one. Once upon a time, before starting building Toaster, we discussed our
plans with some distribution engineers using a fake prototype that
simulated different features and functionality. One of those simulated
features was the ability to access the metadata files. Some people really
liked the idea, and asked if you would be able to edit the source and
generate patches from your changes. Other people got quite worried: they
were thinking of Toaster as a way of interacting with their customers and
provide them easy access to build configuration and artifacts within a
"safe" environment. The ability to access the metadata was perceived as
dangerous and likely to cause them problems, unless there was a
permissions system in place they could use to control access.

I can see the point of the latter people (and we still don't have a
permissions system in Toaster), and the challenges that will come with
things like editing source files in Toaster. So we have so far shied away
from this functionality, because I think we felt we were neither resourced
nor ready to tackle those problems.

There, that's the story. This doesn't mean we should not consider the
feature going forward, but definitely not for the 1.9 release.

Cheers

Belén
 
>
>Regards,
>Ed
>
>> Thanks!
>> 
>> Belén
>> 
>> On 10/07/2015 09:37, "Ed Bartosh" <ed.bartosh at linux.intel.com> wrote:
>> 
>> >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#usingp
>>>>>ok
>> >>>y-
>> >> >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_
>>>>>To
>> >>>as
>> >> >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.
>>>>pd
>> >>f,
>> >>  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 at 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 at 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 at 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#usi
>>>>>>>>ng
>> >>>>>>po
>> >> >>>>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 at yoctoproject.org [mailto:toaster-
>> >> >> >>> bounces at yoctoproject.org] On Behalf Of Michael Wood
>> >> >> >>> Sent: Tuesday, June 23, 2015 9:32 AM
>> >> >> >>> To: toaster at 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 at yoctoproject.org
>> >> >> >>https://lists.yoctoproject.org/listinfo/toaster
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>-- 
>> >> >> >>Alex Damian
>> >> >> >>Yocto Project
>> >> >> >>
>> >> >> >>SSG / OTC 
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >-- 
>> >> >> >_______________________________________________
>> >> >> >toaster mailing list
>> >> >> >toaster at yoctoproject.org
>> >> >> >https://lists.yoctoproject.org/listinfo/toaster
>> >> >> 
>> >> >> -- 
>> >> >> _______________________________________________
>> >> >> toaster mailing list
>> >> >> toaster at yoctoproject.org
>> >> >> https://lists.yoctoproject.org/listinfo/toaster
>> >> >
>> >> >-- 
>> >> >--
>> >> >Regards,
>> >> >Ed
>> >> 
>> >
>> >-- 
>> >--
>> >Regards,
>> >Ed
>> 
>> -- 
>> _______________________________________________
>> toaster mailing list
>> toaster at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster
>
>-- 
>--
>Regards,
>Ed

More information about the toaster mailing list