Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://winetestbot.geldorp.nl/JobDetails.pl?Key=1399
Your paranoid android.
=== WINEBUILD (Wine build VM) === Patch failed
I'm not sure how the bot works but it looks like it concatenated some of my patches together and then applied to them. I have no idea to what Wine version it was since it applies fine on Wine git here. It could be that I'm doing something wrong but I don't see where.
Roderick
On Mon, Apr 12, 2010 at 10:10 PM, Marvin winetestbot@geldorp.nl wrote:
Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://winetestbot.geldorp.nl/JobDetails.pl?Key=1399
Your paranoid android.
=== WINEBUILD (Wine build VM) === Patch failed
From: Roderick Colenbrander
I'm not sure how the bot works but it looks like it concatenated some of my patches together and then applied to them. I have no idea to what Wine version it was since it applies fine on Wine git here. It could be that I'm doing something wrong but I don't see where.
No, this is the bot messing up. For some reason I don't understand yet it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an initial ColorFill regression test.") as the first of this series. That threw everything off.
I'll disable emailing to wine-devel until I've sorted this out.
Ge.
From: Ge van Geldorp
From: Roderick Colenbrander
I'm not sure how the bot works but it looks like it concatenated some of my patches together and then applied to them. I have no idea to what Wine version it was since it applies fine on Wine git here. It could be that I'm doing something wrong but I don't see where.
No, this is the bot messing up. For some reason I don't understand yet it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an initial ColorFill regression test.") as the first of this series. That threw everything off.
I'll disable emailing to wine-devel until I've sorted this out.
Ok, I understand what happened now... This is the sequence of patches you submitted, in the order they arrived in my mail queue (oldest first):
1) [PATCH 4/7] wined3d: Move D15S1 over to the formats table. 2) [PATCH 1/7] wined3d: Move L6V5U5 conversion to the formats table. 3) [PATCH 5/7] wined3d: Move R32G32F convertion to the formats table. 4) [PATCH 3/7] wined3d: Move D24X4S4 to the formats table. 5) [PATCH 6/7] wined3d: Move G16R16/R16G16F conversion to the formats table. 6) 1/3 d3d9: Add an initial ColorFill regression test. 7) [PATCH 2/7] wined3d: Move D24FS8 to formats table. 8) [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
Note the out-of-sequence arrival of number 6). The bot is not smart enough to handle two series from the same author arriving interleaved. It will see everything as one big series until all parts of a series have arrived. In this case, the patch attached to message 6) overwrote the patch attached to message 2) (both have part number 1).
Not sure how to handle this, except by asking people to leave some time before sending another series.
Re-enabling emailing to wine-devel since this is working as designed.
Ge.
On 04/13/2010 12:46 AM, Greg Geldorp wrote:
From: Ge van Geldorp
From: Roderick Colenbrander
I'm not sure how the bot works but it looks like it concatenated some of my patches together and then applied to them. I have no idea to what Wine version it was since it applies fine on Wine git here. It could be that I'm doing something wrong but I don't see where.
No, this is the bot messing up. For some reason I don't understand yet it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an initial ColorFill regression test.") as the first of this series. That threw everything off.
I'll disable emailing to wine-devel until I've sorted this out.
Ok, I understand what happened now... This is the sequence of patches you submitted, in the order they arrived in my mail queue (oldest first):
- [PATCH 4/7] wined3d: Move D15S1 over to the formats table.
- [PATCH 1/7] wined3d: Move L6V5U5 conversion to the formats table.
- [PATCH 5/7] wined3d: Move R32G32F convertion to the formats table.
- [PATCH 3/7] wined3d: Move D24X4S4 to the formats table.
- [PATCH 6/7] wined3d: Move G16R16/R16G16F conversion to the formats table.
- 1/3 d3d9: Add an initial ColorFill regression test.
- [PATCH 2/7] wined3d: Move D24FS8 to formats table.
- [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
Note the out-of-sequence arrival of number 6). The bot is not smart enough to handle two series from the same author arriving interleaved. It will see everything as one big series until all parts of a series have arrived. In this case, the patch attached to message 6) overwrote the patch attached to message 2) (both have part number 1).
Not sure how to handle this, except by asking people to leave some time before sending another series.
Dan's Patchwatcher had more or less the same issue in the beginning, but wasn't that solved?
I think the only issue left was when people sent 2 series of equal patchcounts and they arrive mixed.
Greg Geldorp schreef:
From: Ge van Geldorp
From: Roderick Colenbrander
I'm not sure how the bot works but it looks like it concatenated some of my patches together and then applied to them. I have no idea to what Wine version it was since it applies fine on Wine git here. It could be that I'm doing something wrong but I don't see where.
No, this is the bot messing up. For some reason I don't understand yet it included one of your earlier patches ("[PATCH 08/13] d3d9: Add an initial ColorFill regression test.") as the first of this series. That threw everything off.
I'll disable emailing to wine-devel until I've sorted this out.
Ok, I understand what happened now... This is the sequence of patches you submitted, in the order they arrived in my mail queue (oldest first):
- [PATCH 4/7] wined3d: Move D15S1 over to the formats table.
- [PATCH 1/7] wined3d: Move L6V5U5 conversion to the formats table.
- [PATCH 5/7] wined3d: Move R32G32F convertion to the formats table.
- [PATCH 3/7] wined3d: Move D24X4S4 to the formats table.
- [PATCH 6/7] wined3d: Move G16R16/R16G16F conversion to the formats table.
- 1/3 d3d9: Add an initial ColorFill regression test.
- [PATCH 2/7] wined3d: Move D24FS8 to formats table.
- [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
Note the out-of-sequence arrival of number 6). The bot is not smart enough to handle two series from the same author arriving interleaved. It will see everything as one big series until all parts of a series have arrived. In this case, the patch attached to message 6) overwrote the patch attached to message 2) (both have part number 1).
Not sure how to handle this, except by asking people to leave some time before sending another series.
Re-enabling emailing to wine-devel since this is working as designed.
Ge.
Hey Ge,
you could, instead of only checking for the author, also try to check for the maximum amount of patches. If you find patch [Patch 1/7], I assume you currently wait for all 7 patches. Now if a patch 1/3 comes in between, you'll see that the maximum is different, in this case 3, so you'll know that it's a different patch-set.
In case the maximum is also the same, it's also difficult for a human to see what patch belongs to what patch-set, so that should never happen in the first place. Unless AJ is a psychic of course.
Sven
P.S. Awesome work on the testbot.
Hi Sven,
From: Sven Baars
you could, instead of only checking for the author, also try to check for the maximum amount of patches. If you find patch [Patch 1/7], I assume you currently wait for all 7 patches. Now if a patch 1/3 comes in between, you'll see that the maximum is different, in this case 3, so you'll know that it's a different patch-set.
I thought about that, but the drawback is that a new patch set is started if the submitter mistypes the maximum (e.g. [1/4], [2/4], [3/5], [4/4]). In that case we end up with two incomplete sets. I've also considered taking the DLL name into account if available (most people will include the DLL name in their Subject), but there are valid patch sets spanning multiple DLLs (e.g. 1/3 d3d9: ..., 2/3 wined3d: ..., 3/3 wined3d: ...) so that won't work either. I'll probably go back to using author + maximum as the key and perhaps build a UI so an author can manually select patches belonging to a set and put them in the right order. Then when a set still appears incomplete after a couple of hours a reminder email could be sent to the author asking him to manually group his patches.
In case the maximum is also the same, it's also difficult for a human to see what patch belongs to what patch-set, so that should never happen in the first place. Unless AJ is a psychic of course.
He is ;-)
Ge.
you could, instead of only checking for the author, also try to check for the maximum amount of patches. If you find patch [Patch 1/7], I assume you currently wait for all 7 patches. Now if a patch 1/3 comes in between, you'll see that the maximum is different, in this case 3, so you'll know that it's a different patch-set.
I thought about that, but the drawback is that a new patch set is started if the submitter mistypes the maximum (e.g. [1/4], [2/4], [3/5], [4/4]). In that case we end up with two incomplete sets.
This should be a pretty rare case given that most people will use some generators like 'git format-patch' or 'quilt' for their patch-series. I'd say if such an error ever occurs, the series could be manually fixed/resent. That way, you don't need to code some UI and the authors who have not done a mistake won't need to take an extra step.
Kind regards,
Wolfram
Wolfram Sang wrote:
you could, instead of only checking for the author, also try to check for the maximum amount of patches. If you find patch [Patch 1/7], I assume you currently wait for all 7 patches. Now if a patch 1/3 comes in between, you'll see that the maximum is different, in this case 3, so you'll know that it's a different patch-set.
I thought about that, but the drawback is that a new patch set is started if the submitter mistypes the maximum (e.g. [1/4], [2/4], [3/5], [4/4]). In that case we end up with two incomplete sets.
This should be a pretty rare case given that most people will use some generators like 'git format-patch' or 'quilt' for their patch-series.
People do use those tools and then change their mind. One can see regularly patches like [5/4] or people drop a patch from the series, etc.
I'd say if such an error ever occurs, the series could be manually fixed/resent. That way, you don't need to code some UI and the authors who have not done a mistake won't need to take an extra step.
That isn't very user friendly and at least for the beginning the tool needs to cope with the established and accepted workflow. Once the tool gets part of the patch submission process stuff can be made more strict if it is deemed necessary.
bye michael
From: Wolfram Sang
This should be a pretty rare case given that most people will use some generators like 'git format-patch' or 'quilt' for their patch-series. I'd say if such an error ever occurs, the series could be manually fixed/resent. That way, you don't need to code some UI and the authors who have not done a mistake won't need to take an extra step.
Looking back at my previous post I see that I haven't been very clear. The intent is to automatically process sets that the bot can recognize by itself (by looking at author + xx/yy info) and only have the manual interface as a fallback mechanism.
From: Michael Stefaniuc
That isn't very user friendly and at least for the beginning the tool needs to cope with the established and accepted workflow.
Totally agree, the tool should support the developers, not the other way around. However, humans are much better at pattern recognition than computers, so it might be advantageous to have a mechanism whereby a human can nudge the tool in the right direction.
Ge.
-
Greg Geldorp -
Michael Stefaniuc -
Paul Vriens -
Roderick Colenbrander -
Sven Baars -
winetestbot＠geldorp.nl -
Wolfram Sang