Re: [Webhob] task types and outcomes

[Paul Eggleton <paul.eggleton@linux.intel.com>]

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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre