[Toaster] More Projects design (YP6232)
Barros Pena, Belen
belen.barros.pena at intel.com
Wed Jul 9 11:48:01 PDT 2014
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" <david.reyna at windriver.com> 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:belen.barros.pena at intel.com]
>> Sent: Tuesday, July 08, 2014 6:20 AM
>> To: Reyna, David; DAMIAN, ALEXANDRU; Lerner, Dave; Ravi Chintakunta
>> (ravi.chintakunta at timesys.com); Amit Kumar Chaudhary; Wymore, Farrell
>> Cc: toaster at yoctoproject.org
>> 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" <belen.barros.pena at intel.com>
>> 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
>> >
>>
>
More information about the toaster
mailing list