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.webm 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. Thanks! Belén On 10/07/2015 09:37, "Ed Bartosh" <[email protected]> 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#usingpok >>>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" >><[email protected]> >> >> 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" >><[email protected]> >> >> >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 >> >> >><[email protected]> 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#using >>>>>>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. >> >>The >> >> >>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: [email protected] [mailto:toaster- >> >> >>> [email protected]] On Behalf Of Michael Wood >> >> >>> Sent: Tuesday, June 23, 2015 9:32 AM >> >> >>> To: [email protected] >> >> >>> 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 >> >> >>[email protected] >> >> >>https://lists.yoctoproject.org/listinfo/toaster >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>-- >> >> >>Alex Damian >> >> >>Yocto Project >> >> >> >> >> >>SSG / OTC >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >-- >> >> >_______________________________________________ >> >> >toaster mailing list >> >> >[email protected] >> >> >https://lists.yoctoproject.org/listinfo/toaster >> >> >> >> -- >> >> _______________________________________________ >> >> toaster mailing list >> >> [email protected] >> >> https://lists.yoctoproject.org/listinfo/toaster >> > >> >-- >> >-- >> >Regards, >> >Ed >> > >-- >-- >Regards, >Ed -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
