Re: Buildhistory in action

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

On Thursday 19 January 2012 13:08:03 Richard Purdie wrote:
> If I change into tmp/buildhistory and show the last commit the result is
> included below. Since the version changed, the diff isn't as readable as
> would be ideal, however reading through it clearly shows the .a files
> moving to the staticdev packages with no unintended changes as far as I
> could tell.
> 
> One of my big worries with the staticdev changes is any unintended
> packaging changes. This lets me view the changes more precisely which
> can only lead to higher quality regression spotting for the project. I'd
> like to suggest more people start enabling this and using it to check
> the changes they're making.
> 
> I know Paul is working on tools to better display these changes too and
> those will help make these diffs easier to read.

There's the command line buildhistory-diff tool (in scripts/) already, and this
will query the git repository and report just the changes that might represent
regressions, in a form that's a bit easier to read than git diff. For example
(simulated):

paul@helios:~/poky/poky/build/tmp/buildhistory$ ~/poky/poky/scripts/buildhistory-diff . HEAD^^
Changes to images/qemux86_64/eglibc/core-image-minimal (files-in-image.txt):
  /etc/anotherpkg.conf was added
  /sbin/anotherpkg was added
  * (installed-package-names.txt):
  *   anotherpkg was added
Changes to images/qemux86_64/eglibc/core-image-minimal (installed-package-names.txt):
  anotherpkg was added
packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
  * PR changed from "r0" to "r1"
  * PV changed from "0.1.10" to "0.1.12"
packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
  * PR changed from "r0" to "r1"
  * PV changed from "0.1.10" to "0.1.12"                                                                                                                         

For those that may not be aware I'm also working on a web frontend to
view/manage these changes more effectively (utilising the same backend code),
however it still needs quite a bit of work.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre