[Toaster] More Projects design (YP6232)

Reyna, David david.reyna at windriver.com
Fri Jul 11 00:16:30 PDT 2014


Hi Belén,

My comments are in-line...

> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena at intel.com]
> Sent: Wednesday, July 09, 2014 11:48 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)
> 
> 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).

I am flexible about this wording - I just wanted to bring this question to your attention.

I am trying to fully understand your words and assumptions. What is your "Imported layer source"? Is that an object separate from the user's layer? When you write "effectively that imports the layer information" are you implying a physical copy or just a logical reference?

In the call you mentioned that you expected that the imported layers would be in a bare git clone format. While this is true for the distribution content, I want to mention again that we expect customers will have their custom layers in a normal directory format since they would be under active development and not compressed into a repo.  We need to support both formats.

BTW, this brings to mind a related question. Is it the assumption that any imported layer must exist both on the host (so that it can be parsed) but also at the remote build machine (so that the builder can use it)? If not, does this indeed imply a copy action of the layer to that remote builder? What is our plan and guidance to the users here?

> >
> >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.

Ok.

> >
> >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.

Ok.

> >, 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.

Ok.

> >
> >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.

Ok.

> >
> >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.

My mum will be so happy :-)

> >
> >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)?

I will think about your question. I understand your point, and the duplication does help the developer at the (hopefully) small cost of code duplications.

> The notification should also show up in the build dashboard page, by the
> way, but I haven't had time to document this yet.

Ok.

> >
> >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.

I am fine with your analysis.

- David

> 
> >
> >- 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