[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: failure rewriting Patchy
From: |
Graham Percival |
Subject: |
Re: failure rewriting Patchy |
Date: |
Sat, 4 Feb 2012 12:16:27 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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