Hi David, Thanks for this. These reviews really help. I am going to explain the reasons behind the decisions we made in relation to your questions to give you some background, but everything is very much open to change, so feel free to press your case or suggest alternatives if you don't agree with the explanations :)
On 09/07/2014 06:04, "Reyna, David" <[email protected]> wrote: >Hi Belén, > >I have done a pass at your updated design document. You seem to have >fully addressed the edge cases and multiple workflow possibilities. > >I have just a few comments. > >1) Page 16 > >The term "Import Layers" implies to me a copy action (e.g. Word, web >design programs, Photoshop, iMovie, ...). I wonder if an alternate phrase >like "Register Layers" or "Include Layers" would be closer to the actual >action? I agree the wording might not be the right one. I chose "Import" because effectively that imports the layer information to an "Imported" layer source that will behave in the same way as any other layer source (will give you suggestions for layers, targets, machines and distros it knows about, and allow you to browse and search the layers in that source). When it comes to filter all layers by layer source, "Imported" seemed to work best ("Registered" or "Included" seem a bit generic). > >2) Page 19 > >There is a state where you write "Toaster does not know which added layer >provides the target." > >Can I assume that this only occurs when the user manually adds a target >but Toaster cannot find a layer that provides it? This happens when Toaster cannot find an "added" layer that provides the target. All target suggestions you get come from the targets provided by the added layers (not from the targets provided by all the layers known to Toaster). This is to make sure Toaster does not add layers "behind your back". For example, let's pretend that I just created a project and I have only the Yocto Project layers there: meta, meta-yocto and meta-yocto-bsp. If I want to build a target called gnuradio-dev-image, I will not get a suggestion for that target because that target is provided by the meta-sdr layer, which is not in my list of added layers. If I add gnuradio-dev-image to my list of targets, that is what I call in the design document an unknown target: Toaster will show me the warning icon, and when I hover over it will suggest adding meta-sdr because it knowns it provides that target (Toaster knows because meta-sdr is included in the OpenEmbedded layer source). My initial design provided target suggestions from all the layers known to Toaster, and if you picked one that was not provided by one of your added layers, Toaster would add the layer (and all its dependencies) to the project. In the above case, if you selected gnuradio-dev-image it would add meta-sdr and meta-openemebedded. The problem with this is that it might not be what you want. I might have a layer called meta-myversionof-sdr that also includes a target called gnuradio-dev-image, but Toaster might not know yet because I have just imported the layer and it has never been built. You might want gnuradio-dev-image to be provided by meta-myversionof-sdr, not by meta-sdr. This was the problem that was raised by Paul and Alex, who were wary of Toaster being "too smart" and imposing options on you. In the example above, Toaster going off and adding layers to the list becomes a hassle, because you will either have to undo what Toaster has done, or be subjected to modal messages of the type: "this target is provided by layer blah. Would you like to add this layer to your project?", which are quite intrusive and can get annoying. > >If I understand correctly, when toaster cannot not find a parent layer it >will initially leave the target in blue It will leave it in black with the warning icon next to it: blue targets are links to a target details page that provides additional information about the target. But that information is only available when Toaster knows which layer provides the target, so when Toaster does not know that, target names cannot be links (i.e. blue), and they are just black. >, and only move it to red if a build is attempted and it fails? In other >words, even if Toaster cannot associate a target with a layer it will >still treat it normally (albeit without pop-up parent layer information)? Almost normally: it will show the warning icon as a way to tell you that everything might not be quite right. As explained above, Toaster is trying to be helpful without being intrusive or imposing anything on you (that's the intention, in any case). If the build fails because a target is not provided, it will fail very quickly, and Toaster will tell you exactly what the issue is and which target is causing it. > >I see that you cover the build-failure case on page 24, but I did not >notice where you cover the layer-not-found-but-target-works case. Nothing needs to be done in this case, I think. Toaster learns stuff as it builds, so once the build runs, chances are that Toaster will know which of the added layers provided the target, so it can remove the warning icon, turn the target into a link and give you the tooltip with parent layer information. > >3) Page 21, et. al. > >As a nit-pick, I would suggest the alternate wording "From the layer >information that Toaster has currently, it thinks ...", to put the actor >(Toaster) in the first part of the sentence fragment, and to also not end >that fragment with a verb (I think that my mother frowns on that). Will do. I don't want your mum to get upset when configuring her builds ;) All the copy has been written by me, which means it needs to be reviewed, so if you find that kind of stuff, please let me know so I can correct it. > >4) Page 24 and Page 25 > >Your design shows two places to list possible missing layers, once in the >layer list hovers and once in the build results. Do you really want this >duplication? I just wonder if it is worth considering a consolidation in >order to not do the display and computation code twice, or if ease-of-use >justifies this effort? I thought the error icon by itself might be too subtle, and the information too important to be hidden inside some message that only appears on hover. but I could be wrong. I do get the duplication bit, though. Maybe we could just keep the notification (and remove the message on hover)? The notification should also show up in the build dashboard page, by the way, but I haven't had time to document this yet. > >5) Page 32 > >You write "... since Toaster will not know about machines from imported >layers that have not been parsed yet". > >This is of course a general limitation of bitbake for the >pre-configuration state. My general question is this then: should we and >can we provide an action (perhaps a simple build target) that will >trigger bitbake to do that initial parse, so that the user can directly >and immediately improve the information available to them? We did consider this at some point, but concluded that the parse would take too long to be useful, and that people would get tired of waiting and fire the build anyway. We also thought that, because builds fail so quickly when something is not provided, running a build might be actually a faster way of flagging the problem than triggering a bitbake parse. We could be wrong though: happy to discuss. > >- David > > >> -----Original Message----- >> From: Barros Pena, Belen [mailto:[email protected]] >> Sent: Tuesday, July 08, 2014 6:20 AM >> To: Reyna, David; DAMIAN, ALEXANDRU; Lerner, Dave; Ravi Chintakunta >> ([email protected]); Amit Kumar Chaudhary; Wymore, Farrell >> Cc: [email protected] >> Subject: Re: More Projects design (YP6232) >> >> And still a bit more: how to change the "Project details" (the name, the >> owner, and that kind of thing). >> >> Design document attached to Bugzilla entry: >> >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6232 >> >> >> New stuff in pages 39 to 42. >> >> Belén >> >> On 07/07/2014 15:49, "Barros Pena, Belen" <[email protected]> >> wrote: >> >> >I've added: >> > >> >* Queued and cancelled builds (pages 10-11) >> >* Quick add option for targets (pages 27-29) >> >* Deleting layers and targets (page 30) >> >* Changing machine and distro (pages 31-38) >> > >> >Design document attached to Bugzilla entry: >> > >> >https://bugzilla.yoctoproject.org/show_bug.cgi?id=6232 >> > >> >Cheers >> > >> >Belén >> > >> > -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
