Dan Kegel wrote:
On Mon, Aug 11, 2008 at 4:31 PM, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
When running tests for the patch, I think we should just run the tests
of the dlls that are affected direct;y or indirectly by that change.
its running the tests for entire wine, which is very time
On Tue, Aug 12, 2008 at 1:01 AM, Paul Vriens [EMAIL PROTECTED] wrote:
Dan Kegel wrote:
On Mon, Aug 11, 2008 at 4:31 PM, Vijay Kiran Kamuju [EMAIL PROTECTED]
wrote:
When running tests for the patch, I think we should just run the tests
of the dlls that are affected direct;y or indirectly by
Ilya Shpigor [EMAIL PROTECTED] wrote:
- /* why do we notify to es-hwndParent, and we send this one to GetParent()?
*/
+ /* All notifies are send to es-hwndParent
+ * except the WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT.
+ * Its are send to the current parent.
+ */
hbrush =
Ilya Shpigor [EMAIL PROTECTED] wrote:
What is the difference between wpParent1 and wpParent2 besides slightly
different indentation and 1 superfluous 'break' statement?
- /* why do we notify to es-hwndParent, and we send this one to
GetParent()? */
+ /* All notifies are send to
couldn't you instead when the patchwatcher takes the patch it assigns it a
patch # and require if there is a patch dependency? that the person put into a
comment REQ_PATCH: 123456,15456, etc.. ? That way when a diff is done for the
patch it would appear in the patch diff?
Then patchwatcher
Am Montag, den 11.08.2008, 17:34 -0700 schrieb Dan Kegel:
Yes. I already changed the success message to make more sense,
and added background colors of green and red for success and failure.
I dislike the implementation, while I like the idea. You now have:
a:visited { color: #FF; }
.fail
On Tue, Aug 12, 2008 at 6:47 AM, [EMAIL PROTECTED] wrote:
couldn't you instead when the patchwatcher takes the patch it assigns it a
patch # and require if there is a patch dependency that the person put into
a comment REQ_PATCH: 123456,15456, etc.. ?
Yes, perhaps if patchwatcher catches on
Yes. I already changed the success message to make more sense,
and added background colors of green and red for success and failure.
I dislike the implementation, while I like the idea. You now have:
a:visited { color: #FF; }
.fail { background color: #ff5050; }
At least on my laptop
Michael Karcher [EMAIL PROTECTED] wrote:
Yes. I already changed the success message to make more sense,
and added background colors of green and red for success and failure.
I dislike the implementation, while I like the idea. You now have:
a:visited { color: #FF; }
.fail { background
On Mon, Aug 11, 2008 at 11:59 PM, Dmitry Timoshkov
[EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
+BOOL WINAPI ConvertToAutoInheritPrivateObjectSecurity(
+PSECURITY_DESCRIPTOR ParentDescriptor,
+PSECURITY_DESCRIPTOR CreatorDescriptor,
+
Am Dienstag, den 12.08.2008, 08:26 -0700 schrieb Dan Kegel:
Yeah, I know. I fiddled with the colors for a while, but not very
effectively.
I'm partly color-blind, and am not really the best person to
work on the look of the reports page. If somebody else would like
to get the colors right,
On Tue, Aug 12, 2008 at 10:29 AM, Reece Dunn [EMAIL PROTECTED] wrote:
I use GMail to do something similar - tag mail I send to wine-patches
with a 'wine-tracking' label, as well as the 'wine-patches' label it
gets from the mailing list filter I have. This allows me to see all
active patches I
So, one of the things one learns when writing a
patch robot is that flaky tests are very annoying.
Each time it gets a new git tree,
the robot does five baseline make -k test runs,
remembers the tests that fail, and doesn't penalize
patches for failing any of those tests. See
On Mon, 2008-08-11 at 22:24 -0700, Dan Kegel wrote:
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Zachary Goldberg [EMAIL PROTECTED] wrote:
Policy is that all patches should be independent, no?
There is no such a policy. Dependent patches are marked as
1/xx, 2/xx, ... xx/xx.
That's a
On Tue, Aug 12, 2008 at 1:39 PM, Adam Petaccia [EMAIL PROTECTED] wrote:
What about checking for a string in the email like patchwatchignore;
if for some reason the patch is known to cause a failure the e-mail
might read like:
patchwatchignore
This depends on Harald's patch from
2008/8/12 Dan Kegel [EMAIL PROTECTED]:
On Tue, Aug 12, 2008 at 6:47 AM, [EMAIL PROTECTED] wrote:
couldn't you instead when the patchwatcher takes the patch it assigns it a
patch # and require if there is a patch dependency that the person put into
a comment REQ_PATCH: 123456,15456, etc.. ?
Am Dienstag, den 12.08.2008, 10:58 -0700 schrieb Dan Kegel:
The list is currently
user32:msg.c
user32:input.c
Same problems here. Metacity 2.23.21, compiled myself.
d3d9:visual.c
ddraw:visual.c
The last two are really nasty. Take a look at ddraw/tests/visual.c:2624.
It makes a kind of
On 8/11/08, Ismael Barros [EMAIL PROTECTED] wrote:
Actually the thread stuff is a very good idea, I'll take a look.
I tried launching each tests in a new thread, but a lot of tests
failures arise, sometimes even with segfaults or deadlocks. Looks like
the original implementation of dplay doesn't
While debugging some force-feedback issues ran into an interesting problem.
The size of one struct from include/linux differs between 32-bit and 64-bit.
That wouldn't be a major problem except that size is the part of the ioctl()
request. Which results in EINVAL.
In more details:
input.h:
19 matches
Mail list logo
