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" <[email protected]> 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. _______________________________________________ webhob mailing list [email protected] https://lists.yoctoproject.org/listinfo/webhob
