Re: checking 2240

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote:
>> 
>> So please accept my apologies that I can't defend this patch further
>> today.  It does not mean that I am not serious about it, and I
>> definitely believe that if Graham double-checks the comments on this
>> patch, he'll find the reason for our difference in test results.
>
> We seem to have a failure to communicate here.  I shall be blunt,
> although I am not angry with you.
>
> I will not be doing any manual investigations about 2240 (or any
> other patch, for that matter).

If you have indeed stale files in your tree due to the stupid Rietveld
way of working, you better not do automatic investigations about any
other patch, either, until you have removed them.

> I will therefore not do any manual fiddling around to test a patch or
> staging.  Anything that fails the automatic process is rejected; if
> the process needs to be fixed, then fix the process.

_You_ refuse to run "git clean" because you don't want to risk having to
run "make test-baseline" too often (it probably would not be affected).
So you are not working with clean directories, and previous tests mess
up the result.

> With respect to this patch, you have 4 options:
> - modify Patchy to do the appropriate build stuff.
> - recruit somebody else to modify Patchy for you.
>   (I don't want to put Mike on the spot, but a week ago I sent
>   him this same email and he fixed the relevant problem in Patchy,
>   so he might be willing to modify Patchy for this)
> - skip the review process by manually marking it as Patch-review
>   yourself.  I do not object to this, but be aware that you are
>   therefore vouching for the patch in a much more serious way.
> - abandon the patch.

I am skipping the review in this case.  I tested it back and forth on my
system, and it is clear that this is a case of the automatic tests going
wrong, very likely because of a dirty work tree left from a previous
test and an error from "git apply" due to not actually fully applying
the patch because of those residues getting left in place.

If you don't remove the stale files from your work tree eventually, your
test results will diverge further and further from reality.  And you'll
get problems whenever you test a patch that contains new files.  Any
revisions to those files will never make it from the Rietveld patch into
your tree.

-- 
David Kastrup