Re: [Webhob] task types and outcomes

["Barros Pena, Belen" <belen.barros.pena@intel.com>]

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?

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

The first one reflects exactly what BitBake does; I would think the second
one gives me a better picture of how a certain outcome was reached.

Belen


On 28/05/2013 17:24, "Paul Eggleton" <paul.eggleton@linux.intel.com> wrote:

>On Tuesday 28 May 2013 16:16:07 Barros Pena, Belen wrote:
>> I am looking into the BitBake task-related information we'll display in
>> Web Hob. Looking back to the agency work, it seems we identified 2 types
>> of tasks: sstate tasks and built tasks.
>> 
>> Sstate tasks can have 3 possible outcomes: missed, completed and failed.
>
>Correct (although I wonder if there is a further distinction between
>missed 
>completely, and missed due to some change i.e. one or more sstate
>packages 
>exist for the task but the signatures are different).
> 
>> Built tasks can have 3 possible outcomes: previously built, completed
>>and
>> failed.
>
>Correct.
> 
>> Looking at this now, I am not sure I understand the difference between a
>> missed sstate task and a built task, and between a previously built task
>> and an sstate task:
>> 
>> * Wouldn't a missed sstate task become a built task?
>
>Yes.
>
>> * Wouldn't a previously built task be an sstate task?
>
>If the definition of "previously built" is "previously built within the
>same 
>build directory and not subsequently cleaned", then because there is a
>stamp 
>present for the task, it doesn't even need to look at sstate for the task.
>
>Cheers,
>Paul
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.