Re: [PATCH] Modify buildstats to be merged inside buildhistory

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Monday 04 November 2013 12:42:59 Stoicescu, CorneliuX wrote:
> On Monday 04 November 2013 14:35:00 Richard Purdie wrote:
> > 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.

Just to round this off - I still have some reservations about adding this data 
in its current form to buildhistory, but being able to associate it with the 
build and other changes that occurred at the same time is valuable. Let's add 
it under ${BUILDHISTORY_DIR} using ${BUILDNAME} as a subdirectory as Richard 
suggests, and then later we can add some analysis code and maybe optional 
automatic pruning of old data to keep things tidy.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre