Re: failure rewriting Patchy

[Graham Percival]

On Sat, Feb 04, 2012 at 11:57:24AM +0100, David Kastrup wrote:
> "Phil Holmes" <address@hidden> writes:
> 
> > I've not looked at the attached file, but what were you trying to do
> > and what caused problems, Jan?
> 
> 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.

This is probably solvable by copy&pasting 2-4 lines of code from
compile_lilypond_test.py to itself.  If the solution isn't already
in there, then it's a matter of adding 2-4 lines of code, most of
which will be the git command.

> b) work tree management.  test-patches.py checks out a git tree, makes a
> 
> c) test baseline management.  Since the test baseline output sits in

An alternate idea is to improve the lilypond build system.  If we
don't have a "make dep-clean" then maybe it would be good to do
that.

I know that I always say that you cannot trust a partially-built
tree and you should always completely remove your old build tree
before starting a new build... but that's not precisely a good
state of affairs.


Also remember that the precise problem with 2240 was that my
$LILYPOND_GIT was pointing to the wrong user and that nobody else
could duplicate the behavior I was seeing (because it was an admin
screw-up on my personal system).  I'm still not certain if
anything actually *needs* to change with respect to b) and c).
I think the best way forward is to have documentation in the CG
about how to run stable-merge, test it with a few people, then do
the same for patch-new-testing.

If multiple people have problems testing a certain commit, then
obviously more investigation is needed.  But until then, I think
the best way forward it documentation and more widespread usage.

- Graham