28 Sep
2012
28 Sep
'12
11:14 p.m.
But you don't want to do this anyway: you want to
use 'git bisect',
which is designed for this sort of binary-searching for bugs with
unknown origin. (Note that after every 'git bisect good/bad' you will
need to do a 'git submodule update' to bring the submodules up to date
properly.)
Thank you for the explanation.
Like 'git reset --hard', seems every explanation I read is focused on a repo for a
single product/package and not a multi-layered repo like Trinity. As I mentioned in a
previous mail, the Trinity repo is really 134 (or so) repos, or 134 products. Whereas I
can easily 'git reset --hard' or 'git bisect' an individual Trinity
package/module, I can't easily bisect the entire Trinity source tree. At least, I am
not seeing how to do this.
The particular regression (bug reports 1111 and 178) I am helping debug involves several
Trinity packages. That is, at least tdelibs and k3b are involved, probably tdebase too.
Yet tdelibs affects all packages. The regression might have been introduced in the many
commits with the new TDEHW libs, which includes tdebase. Any reset or bisect of tdelibs or
tdebase likely requires all dependent packages to be reset/bisected too.
The challenge is that Trinity packages are all interrelated. Proper testing requires all
packages be rebuilt the same as they were on the same date.
For me to troubleshoot by building packages from a specific date requires me to reset
(bisect) many Trinity modules, possibly all.
At this point nobody yet knows when this regression started because the particular feature
is not something everybody uses every day. Just today, we discovered the bug is masked
when used through NFS shares, hence a previous leaning the problem was distro specific or
PEBKAC.
Based upon the bug report dates, the regression appeared some time before the middle of
July. A package set I found in my backups from March 27 does not exhibit the regression,
but based upon the recent news about NFS masking, I should retest those packages without
that layer.
I don't mind the work involved with rebuilding packages, testing, etc. I just am not
seeing how to get there because of the complex relationship of all Trinity packages. :(
I might start storing tarball snapshots each time I re-sync my local tree and then always
build only from tarballs rather than my local GIT tree. For sure I'm going to become
more rigorous about archiving package sets, which would allow faster testing of
regressions.
Darrell