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

[Stoicescu, CorneliuX]

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> Sent: Monday, November 04, 2013 2:35 PM
> To: Paul Eggleton
> Cc: Stoicescu, CorneliuX; openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Modify buildstats to be merged inside
> buildhistory
> 
> 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.

We could use add code to buildhistory-diff and make it return comparison buildstats data for a set of builds ?
Usually people look at statistics for a certain task at a time and such a tool could actually make things easier.

Regards,
Corneliu