[OE-core] [PATCH] Modify buildstats to be merged inside buildhistory

[Richard Purdie]

On Mon, 2013-11-04 at 12:14 +0000, Paul Eggleton wrote:
> On Monday 04 November 2013 09:31:19 Richard Purdie wrote:
> The basic idea with buildhistory is to only keep the latest version of data 
> stored within it, on the assumption that you could always get previous 
> versions from the git history; this also makes comparisons to previous 
> versions straightforward.

This makes sense for absolute value data. The task build statistics are
not entirely "absolute" data though and having to traverse many
checkouts trying to build up say "average task timing" might be
problematic.

> As far as timestamps go, BUILDNAME does go into the commit message; if it 
> helps we record the metadata revisions corresponding to the build in the 
> buildhistory repo as well (in a "metadata-revs" file).

Currently the main use of the data is to say "visualise this build"
where you're building a target or set of targets. We name the build
after the first item in the list of build targets.

The logged data is useful both as part of a set which are viewed
together and individually on a task basis so see how much CPU/Disk a
given task uses and how that changes over time.

The tricky part is firstly that we should really use a true buildname,
secondly that we need both the set of data and data per target.

If we just logged data per target, we could overwrite any previous data
but that would break usage as a set.

> If we do want to keep the builds split out in separate per-build directories 
> then what are we gaining by trying to push buildstats into buildhistory in the 
> first place?

We have a need to be able to merge and store build statistic data which
build history already does well. The question is whether it makes sense
to use the same mechanism or not since there are commonalities and
differences. Having two data storage systems and repositories doesn't
make a lot of sense.

I'm not sure this makes a solution much clearer but it does hopefully
better explain the challenge.

Cheers,

Richard