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