On Fr, 2008-09-05 at 10:24 -0700, Dan Kegel wrote:
The results page
http://kegel.com/wine/patchwatcher/results/
looks nice and green;
Opps, all developer send there Patches in September with 09 as minute,
and in August with 08 ...
:-)
And it would be very nice, when you hide the
On Tue, Sep 9, 2008 at 11:37 AM, Detlef Riekenberg [EMAIL PROTECTED] wrote:
http://kegel.com/wine/patchwatcher/results/
Opps, all developer send there Patches in September with 09 as minute,
and in August with 08 ...
Whoops!
And it would be very nice, when you hide the Email-Address to
2008/9/9 Dan Kegel [EMAIL PROTECTED]:
And it would be very nice, when you hide the Email-Address to
block the bots, who collect spam targets.
Is that needed, given how the addresses are in the open on
the mailing list and all its archives?
I doubt it, we're probably on every possible spam
OK, I've checked in the updated Patchwatcher source
http://code.google.com/p/winezeug/source/detail?r=177
and have turned email notifications back on.
I also told it to rerun the most recent 11 patches,
just to test that it's sending the good patches to
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
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
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
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.. ?
On Sat, Aug 9, 2008 at 9:01 PM, Dan Kegel [EMAIL PROTECTED] wrote:
For the moment, the results only go to a web page,
http://kegel.com/wine/patchwatcher/results/
Most of the results there right now are just test messages
so you can see how it will look when real patches
with various problems
Am Montag, den 11.08.2008, 09:45 -0700 schrieb Dan Kegel:
The scripts now run conformance tests and report regressions.
Does Ditto, but just the new error:end of output mean that there are
no new errors?
Regards,
Michael Karcher
On Mon, Aug 11, 2008 at 10:13 AM, Michael Karcher
[EMAIL PROTECTED] wrote:
Am Montag, den 11.08.2008, 09:45 -0700 schrieb Dan Kegel:
The scripts now run conformance tests and report regressions.
Does Ditto, but just the new error:end of output mean that there are
no new errors?
Yes. Sorry,
Hi,
I have one more concern.
Its regarding running of tests.
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 consuming.
What will happen if we have
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 consuming.
True,
On Mon, Aug 11, 2008 at 7:42 PM, Dan Kegel [EMAIL PROTECTED] 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
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ok I was expressing my concern as it took around 2-3hrs to see my
patch in the patchwatcher.
It's running on a 1GHz single core machine right now.
I'll probably put it on something rather faster.
Also as you you running the wine tests all for each
On Mon, Aug 11, 2008 at 8:34 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ok I was expressing my concern as it took around 2-3hrs to see my
patch in the patchwatcher.
It's running on a 1GHz single core machine right now.
I'll probably put it on something
On Mon, Aug 11, 2008 at 8:34 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ok I was expressing my concern as it took around 2-3hrs to see my
patch in the patchwatcher.
It's running on a 1GHz single core machine right now.
I'll probably put it on something
Zachary Goldberg [EMAIL PROTECTED] wrote:
[much quoted text]
Please trim the quotes down a bit when you reply...
Dan, how are you handling the case when Alexandre floods the list with
commits?
See refresh_tree(),
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Also add Yellow for ignored patches.
Let me think on that a bit. Probably.
For ignored patches /i would like to add a second pass, when have to
check if the patch is generated by git or not
if not patch is being ignored now, for that we need to
On Mon, Aug 11, 2008 at 11:02 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Also add Yellow for ignored patches.
Let me think on that a bit. Probably.
For ignored patches /i would like to add a second pass, when have to
check if the patch is generated
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ahh... I forgot how to handle dependent patches, if they are not in a
patch series
I don't know if there's a good way to handle those.
Maybe just encourage people not to send them :-)
On Mon, Aug 11, 2008 at 11:52 PM, Dan Kegel [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Ahh... I forgot how to handle dependent patches, if they are not in a
patch series
I don't know if there's a good way to handle those.
Maybe just encourage people not to send them
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.
--
Dmitry.
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 patch series, and patchwatcher handles that ok.
There's
Dan Kegel [EMAIL PROTECTED] wrote:
That's a patch series, and patchwatcher handles that ok.
There's another kind of dependent patch, where somebody
says This requires Harold's patch from yesterday.
Patchwatcher probably isn't going to handle that ever.
Well, that happens not that often, so
For the moment, the results only go to a web page,
http://kegel.com/wine/patchwatcher/results/
Most of the results there right now are just test messages
so you can see how it will look when real patches
with various problems are received.
The scripts are a bit ugly, so expect problems to
On Sat, Aug 9, 2008 at 9:01 PM, Dan Kegel [EMAIL PROTECTED] wrote:
For the moment, the results only go to a web page,
http://kegel.com/wine/patchwatcher/results/
Most of the results there right now are just test messages
so you can see how it will look when real patches
with various problems
35 matches
Mail list logo
