From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (dan.rpsys.net [93.97.175.187]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 5AC4EE014B4 for ; Wed, 29 May 2013 14:39:57 -0700 (PDT) Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r4TLhrVH024650; Wed, 29 May 2013 22:43:53 +0100 X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5oqcZfnHTYs3; Wed, 29 May 2013 22:43:53 +0100 (BST) Received: from [192.168.3.10] (rpvlan0 [192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r4TLhXms024619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 29 May 2013 22:43:45 +0100 Message-ID: <1369863547.14887.246.camel@ted> From: Richard Purdie To: Paul Eggleton Date: Wed, 29 May 2013 22:39:07 +0100 In-Reply-To: <1472366.Q2PehFIGti@helios> References: <1472366.Q2PehFIGti@helios> X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Cc: "Dragomir, CalinX L" , "Zhang, Jessica" , "webhob@yoctoproject.org" Subject: Re: [Webhob] task types and outcomes X-BeenThere: webhob@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:39:58 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2013-05-29 at 16:57 +0100, Paul Eggleton wrote: > On Tuesday 28 May 2013 17:17:35 Barros Pena, Belen wrote: > > Thanks, Paul. I guess we need to nail down what is that we are trying to > > achieve by reporting sstate tasks vs. built tasks vs. previously built > > tasks. From what I can remember, the main questions users need answered > > are: > > > > * Why is this a built task when I was expecting it to reuse sstate objects? > > * Why is this an sstate task when I was expecting it to build from scratch? > > These are common questions yes. > > > If those are indeed the main questions we need to answer, reporting missed > > sstate tasks and built tasks as one probably makes things easier. The > > metaphor would be a single task with a certain life cycle, and not 2 > > separate tasks. So, "BitBake detected changes in the inputs for task x and > > reran the task" would result in Web Hob reporting a single built task with > > an sstate missed flag. If we report this case through 2 separate tasks > > we'll need to link them to each other, so that users can reach one from > > the other and get a full picture of what BitBake did during the build. > > This is also a viable option, but it will result in a much longer table of > > tasks, with 2 entries for a certain task + recipe combination. > > > > Which way we report tasks impacts the way we structure the Web Hob tasks > > table. From this classification of tasks: > > > > * Sstate > > ** Missed > > ** Completed > > ** Failed > > > > * Built > > ** Previously built > > ** Completed > > ** Failed > > > > We would move to this one: > > > > * Completed > > ** Previously built > > ** Sstate > > ** Built > > *** Sstate missed? Y/N > > *** Sstae failed? Y/N > > > > * Failed > > ** Built > > I think this is a reasonable approach. Although it does slightly obscure the > details of the tasks bitbake is running it's going to be a bit easier for the > user to follow with respect to the information they're most interested in. Sorry about the delayed reply, as you can tell I have a bit of a backlog today :(. I hate to complicate things however there is a touch of added complexity to consider. Imagine we have tasks A which depends upon B which depends upon C. In the no sstate available case, it builds C, then B then A, easy. With sstate, it will try A first. If A is available, it will just install A from sstate and skip B/C. If A is not available, it will try B, install that and skip C. It will then build any missing pieces so it might install B from sstate, then run C. This means that giving the user meaningful numbers of tasks is hard for example. This can probably be presented in the above form fine, I just want to be clear about the subtleties involved. Ideally we do want to try and better convey to the user what happened too in this UI. It could be good if for example we could show that we didn't run C as B was from sstate and hence C wasn't needed. I think the key concept we might also need to work into the UI is "dry run". A mode where you run the build however rather than doing it, it tells you what it would do (i.e. that it would need to run X tasks, Y would be done from sstate). Combined with an indication of why something didn't match, this would be extremely powerful/useful to most users. I have no objection to the form you present above, the key detail is more the dry run concept from the user perspective and start answering questions like "what would bitbake do?". Cheers, Richard