Sporadical test failures for a patch that moves a file

It passed?

When I looked at this, the failure was because install.inc had not been patched properly, so the install was failing. I think that *somehow* the patch in question is not applying correctly.

However, I applied it by hand with a git apply (on the testbot) and it applied just fine.

Is there anything interesting about how this patch was created?

The failing test is http://qa.drupal.org/pifr/test/233128

sun just had a fail that looks like this one: http://qa.drupal.org/pifr/test/233138

Is there a reason to follow this up based on #3 ? Or should we just let it drop?

#1464940-1: database.inc feels lonely in its database ivory tower, see http://qa.drupal.org/pifr/log/233078, failed on #699 first, but then passed on #659.

#1465584: Review external library dependencies in core, see http://qa.drupal.org/pifr/log/233138, failed on #659.

Based on that, I'd exclude a particular testbot failure.

The perhaps unique thing to both patches is that they're trying to move or add new files. However, the second one only adds library files which aren't even used by Drupal.

I think I was wrong about this being a git apply fail; perhaps something happened on that testbot between the time it tested and I looked at it.

Looked at @sun's fail (#2 ) and and at the OP, both on #699, With both I was able to install by manually walking through the install steps (after the testbot laid down the code and failed doing the install).

So it looks to me like these two are probably the same failure, most likely due to something being changed about either the signup steps or... last time we had this problem it was because clean urls were broken. (Nope, that doesn't seem to be the case).

Tested both of these on scratchtestbot and they didn't fail. Hmm. Scratchtestbot is also running rc4 code.

WHOA, but #699 is running a patched rc2. @jthorson? #654 is running a patched rc4... 659 is running patched rc4...

I reset all of them to rc4; not sure how they got into these interesting states.

Now I believe both of these tests are going to pass. Will have to check with jthorson about what was going on, because whatever that code was I think it had some problems.

Marking this fixed as those seem to be testing successfully.

While we were on the 6.x-2.8-rc4 git branch, the code base had been regressed to 6.x-2.7. None of the failure log files contain the testbot id, which was introduced in 6.x-2.8-rc1.

rfay stated that the git diff patches were huge, when in fact, the rc4 compatibility patch I was running (due to qa.d.o not being updated yet) is actually a single line modification ... now that rfay has reverted back to 6.x-2.8-rc4, the tests should pass cleanly; with the only side-effect being that testbot re-confirmation will fail tommorrow unless we can deploy 6.x-2.8-rc4 to qa.d.o, or re-instate the compatibility patch (a 'git apply -R' of this patch) on the testbots themselves.