Re: failure rewriting Patchy

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> I've got a couple of weeks off college now and could look at this.  My
> knowledge of python is small and git even smaller, but would be happy
> to make changes and test them.  Would clearly need the help of the
> people who know what they're doing, tho'.
>
> I've not looked at the attached file, but what were you trying to do
> and what caused problems, Jan?

I have not looked either.  The outline of the work as I understand it
and would tackle it would be

a) git management.  test-patches.py basically takes whatever state its
reference repository index is at as its starting point.  In contrast,
the staging patchy is pretty careful to rely not at all on whatever you
happen to have checked out in which state in the reference repository.

b) work tree management.  test-patches.py checks out a git tree, makes a
test baseline, then applies each of a sequence of patches, tests it
against baseline, then reverts the patch again, does some sort of
cleanup and continues to the next.  That's a bad idea: it should rather
wipe everything clean for the next patch and do a fresh checkout.  Which
would remove the test baseline, so we come to the next point:

c) test baseline management.  Since the test baseline output sits in
directories with a certain filename, it is reasonably easy to move the
baseline results somewhere else (it would probably make sense to create
a separate directory with tar files with the commit id of the baseline
in its filename, in a directory used for such baselines, and only leave
files in there that have been used lately).  That way, each test
baseline is created only once and can be shared between staging patchy
and testing patchy.  This would also mean that if some patch requires
testing against some other baseline (or you want to catch a regression
reasonably fast by comparing against a number of baselines), this would
not require recompilation of the particular test baseline.


I think that Janek has been working on sanitizing step b) by making the
reversal of patches more reliable, but probably this would become easier
if c) was tackled first and thus it became feasible to do a complete
brainless wipeout as step b).

-- 
David Kastrup