Re: patchwatcher status: online but no email
On Thu, 2008-11-06 at 09:29 -0800, Dan Kegel wrote: > > Would you settle for static alternating colors? > I'm kind of anti hover highlight. IIRC there was a recent study claiming that alternating row colors are not all that useful in practice, the on-hover has the advantage of focusing your attention only on the row that you care about. But if you have a problem with that, static colors would be a step forward (and AFAIAC it would be fine). -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: patchwatcher status: online but no email
On Thu, Nov 6, 2008 at 9:07 AM, Dimi Paun <[EMAIL PROTECTED]> wrote: > One suggestion that I have is changing the background color > of the row on hover so you can easily match the result on the > RHS to the Subject, right now that is a bit difficult to > do visually on a wide-screen monitor. Would you settle for static alternating colors? I'm kind of anti hover highlight.
Re: patchwatcher status: online but no email
On Thu, 2008-11-06 at 08:32 -0800, Dan Kegel wrote: > You should see your patch appear at > http://kegel.com/wine/patchwatcher/results Very nice! One suggestion that I have is changing the background color of the row on hover so you can easily match the result on the RHS to the Subject, right now that is a bit difficult to do visually on a wide-screen monitor. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: Patchwatcher status
On Thu, 4 Sep 2008 09:45:52 -0700 "Dan Kegel" <[EMAIL PROTECTED]> wrote: > The new machine has a fairly modern nvidia card, so > more of the tests are actually run. Where can I find the spec of the new machine ? Are you using the closed source driver ? I want to see the full system spec hardware and software please. By the way thank you for your hard work.
Re: Patchwatcher status
On Sun, Oct 26, 2008 at 8:56 PM, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: >> I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 >> more and more often. We really need to set up mock >> servers so test cases don't need to rely on the public >> internet. > > If a test fails due to missing internet access that's a bug > in the test. The test should be skipped in such a case, and > many tests already behave that way. Do you have a list of > broken tests? No, but it will be easy to generate once we have an option to cause all name resolution to return 127.0.0.1.
Re: Patchwatcher status
From: "Dan Kegel" <[EMAIL PROTECTED]> wrote: > I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 > more and more often. We really need to set up mock > servers so test cases don't need to rely on the public > internet. If a test fails due to missing internet access that's a bug in the test. The test should be skipped in such a case, and many tests already behave that way. Do you have a list of broken tests? -- Dmitry.
Re: Patchwatcher status
Kai wrote: > Dan Kegel <[EMAIL PROTECTED]> wrote: >> I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 >> more and more often. We really need to set up mock >> servers so test cases don't need to rely on the public >> internet. > > Samba has a socket wrapper library that fakes network access... I was thinking of something cruder: an option that causes all hostname-to-IP-address resolution to resolve to 127.0.0.1, and then make that the default when running conformance tests. It would break lots of tests, so we would have to mark them todo_wine at the same time, or something.
Re: Patchwatcher status
Dan Kegel wrote: > I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 > more and more often. We really need to set up mock > servers so test cases don't need to rely on the public > internet. > > I'm slowly bringing up a second patchwatcher using > the newly refactored code. I even wrote some documentation > on how to set up a patchwatcher instance: > http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/readme.txt > I don't really recommend anybody (but Rob) try > to do this until we finish working out the bugs, though. > > > > Dan: +1, unless the test case specifically is to test Internet connectivity. James McKenzie
Re: Patchwatcher status
On Sunday 26 October 2008 23:00:51 Dan Kegel wrote: > I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 > more and more often. We really need to set up mock > servers so test cases don't need to rely on the public > internet. Samba has a socket wrapper library that fakes network access. It's not going to work on Wine the way Samba did it (I tried and failed), but I'd be interested in implementing something similar for Wine. Ideally, it'd be compatible to Samba so I can use it for testing, but there's no reason the internet tests can't use that as well. The issue here is that we need to do some pre-setup on the environment we run in, ideally in a way that works on Windows as well. This seems to be hard, so I might be overengineering things. If you think something that for now only runs on Wine would be useful, I can give that a shot. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status
On Thu, Sep 4, 2008 at 10:39 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: > Are there any changes compared to the email notification a week ago? > > I've received several emails about a failure with my patches but it turns > out they were marked as "ignore" or "Patch already in git.". I'm not sure I > should be receiving email about them? That needs fixing still. (Forgot to put that on the to-do list.)
Re: Patchwatcher status
Dan Kegel wrote: > Patchwatcher is almost recovered from its move > to the new machine. I expect to turn email > notifications back on tomorrow. > Hi Dan, Are there any changes compared to the email notification a week ago? I've received several emails about a failure with my patches but it turns out they were marked as "ignore" or "Patch already in git.". I'm not sure I should be receiving email about them? -- Cheers, Paul.
Re: Patchwatcher status
On Fri, Sep 5, 2008 at 2:45 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > Patchwatcher is almost recovered from its move > to the new machine. I expect to turn email > notifications back on tomorrow. > > The old machine could only just barely keep up with > the patch flow. The new machine is two or so times > faster, so it's much, much better at catching up > when a patch flood hits it. > > The new machine has a fairly modern nvidia card, so > more of the tests are actually run. > > To-do list: > > > 9. Figure out why winmm_test.exe.so wave.c always hangs on my new test > machine. > I get this too, it should work after doing a `git diff 3995627de20^ dlls/winealsa.drv | patch -Rp1` and recompiling winealsa.drv http://bugs.winehq.org/show_bug.cgi?id=15030
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 23:58:17 Scott Ritchie wrote: > James Hawkins wrote: > > On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet <[EMAIL PROTECTED]> wrote: > >> Something else... I sometimes reply to patches, and right now that > >> seems to cause patchwatcher to complain that my mail doesn't contain a > >> patch. Would it be possible to do something about that? I suppose > >> patchwatcher could ignore replies without patch. > > > > Is your reply sent to wine-patches? Any replies to a patch should be > > sent to wine-devel unless you're sending another patch. > > Shouldn't wine-patches have it's reply-to field set to wine-devel then? It has. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Dan Kegel wrote: > On Mon, Aug 25, 2008 at 2:05 PM, Kai Blin <[EMAIL PROTECTED]> wrote: > #patchwatcher approve Such a directive would only be recognized if it's alone on a line. >>> The usual positive reply is 'ACK'. I believe it would be simplest to >>> grep the reply message for ACK to see if a reply is positive. >>> >> Dunno, I find myself replying to patches that fix bugs I worked on myself or >> that were in my code with things like "good catch". I agree with Alexandre >> that cases like that are seldom enough that we can probably ignore them. >> > > Around where I work, LGTM (looks good to me) is the reply that > denotes approval. And then there's the Apache convention of +1. > Anyway, I'll recognize one or more of those if and when I get around > to adding a wine-devel listener. Might be a couple weeks. > > Dan: Thank you for adding this. James McKenzie
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 4:58 PM, Scott Ritchie <[EMAIL PROTECTED]> wrote: > James Hawkins wrote: >> On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet <[EMAIL PROTECTED]> wrote: >>> Something else... I sometimes reply to patches, and right now that >>> seems to cause patchwatcher to complain that my mail doesn't contain a >>> patch. Would it be possible to do something about that? I suppose >>> patchwatcher could ignore replies without patch. >>> >> >> Is your reply sent to wine-patches? Any replies to a patch should be >> sent to wine-devel unless you're sending another patch. >> > > Shouldn't wine-patches have it's reply-to field set to wine-devel then? > It is, but for some reason wine-patches is CC'ed instead of the patch sender when you reply-all. -- James Hawkins
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
James Hawkins wrote: > On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet <[EMAIL PROTECTED]> wrote: >> Something else... I sometimes reply to patches, and right now that >> seems to cause patchwatcher to complain that my mail doesn't contain a >> patch. Would it be possible to do something about that? I suppose >> patchwatcher could ignore replies without patch. >> > > Is your reply sent to wine-patches? Any replies to a patch should be > sent to wine-devel unless you're sending another patch. > Shouldn't wine-patches have it's reply-to field set to wine-devel then? Thanks, Scott Ritchie
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 23:20:40 Dan Kegel wrote: > Around where I work, LGTM (looks good to me) is the reply that > denotes approval. And then there's the Apache convention of +1. > Anyway, I'll recognize one or more of those if and when I get around > to adding a wine-devel listener. Might be a couple weeks. Hm, it's getting harder and harder to keep up with this in buildbot. :) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 2:05 PM, Kai Blin <[EMAIL PROTECTED]> wrote: >> > #patchwatcher approve >> > >> > Such a directive would only be recognized if it's alone on a line. >> >> The usual positive reply is 'ACK'. I believe it would be simplest to >> grep the reply message for ACK to see if a reply is positive. > > Dunno, I find myself replying to patches that fix bugs I worked on myself or > that were in my code with things like "good catch". I agree with Alexandre > that cases like that are seldom enough that we can probably ignore them. Around where I work, LGTM (looks good to me) is the reply that denotes approval. And then there's the Apache convention of +1. Anyway, I'll recognize one or more of those if and when I get around to adding a wine-devel listener. Might be a couple weeks. - Dan
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 20:46:51 James Hawkins wrote: > On Mon, Aug 25, 2008 at 1:11 PM, Ken Thomases <[EMAIL PROTECTED]> wrote: > > > > #patchwatcher approve > > > > Such a directive would only be recognized if it's alone on a line. > > The usual positive reply is 'ACK'. I believe it would be simplest to > grep the reply message for ACK to see if a reply is positive. Dunno, I find myself replying to patches that fix bugs I worked on myself or that were in my code with things like "good catch". I agree with Alexandre that cases like that are seldom enough that we can probably ignore them. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 2:46 PM, James Hawkins <[EMAIL PROTECTED]> wrote: > On Mon, Aug 25, 2008 at 1:11 PM, Ken Thomases <[EMAIL PROTECTED]> wrote: >> On Aug 25, 2008, at 1:08 PM, Alexandre Julliard wrote: >> >>> "Dan Kegel" <[EMAIL PROTECTED]> writes: >>> On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > patchwatcher should watch for replies on wine-devel, and > link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. > and mark the patch as needing further action on the submitter's > part. Even if the message says "Great job!"? >>> >>> Sure, that's not the usual case. In most cases when a patch gets a >>> reply >>> it's because it will need changes. There could of course be a way >>> for a >>> submitter to mark the patch as still valid, but the first action >>> should >>> be to take the patch off the list of committable patches. >> >> Perhaps replies meant to approve of a patch could include a special >> textual directive to indicate that patchwatcher shouldn't block the >> patch. Something like: >> >> #patchwatcher approve >> >> Such a directive would only be recognized if it's alone on a line. >> > > The usual positive reply is 'ACK'. I believe it would be simplest to > grep the reply message for ACK to see if a reply is positive. > > -- > James Hawkins > It might be useful if the patch emails themselves contained the patchwatcher documentation. If the mail server could append some instructions onto the patch email we could add some simple directions on how to reply to the patch with an ack etc. Chris
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 1:11 PM, Ken Thomases <[EMAIL PROTECTED]> wrote: > On Aug 25, 2008, at 1:08 PM, Alexandre Julliard wrote: > >> "Dan Kegel" <[EMAIL PROTECTED]> writes: >> >>> On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard >>> <[EMAIL PROTECTED]> wrote: patchwatcher should watch for replies on wine-devel, and link the reply to the patch >>> >>> Yes. The other similar patchwatching systems I found do this, >>> and ours should, too. >>> and mark the patch as needing further action on the submitter's part. >>> >>> Even if the message says "Great job!"? >> >> Sure, that's not the usual case. In most cases when a patch gets a >> reply >> it's because it will need changes. There could of course be a way >> for a >> submitter to mark the patch as still valid, but the first action >> should >> be to take the patch off the list of committable patches. > > Perhaps replies meant to approve of a patch could include a special > textual directive to indicate that patchwatcher shouldn't block the > patch. Something like: > > #patchwatcher approve > > Such a directive would only be recognized if it's alone on a line. > The usual positive reply is 'ACK'. I believe it would be simplest to grep the reply message for ACK to see if a reply is positive. -- James Hawkins
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Aug 25, 2008, at 1:08 PM, Alexandre Julliard wrote: > "Dan Kegel" <[EMAIL PROTECTED]> writes: > >> On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard >> <[EMAIL PROTECTED]> wrote: >>> patchwatcher should watch for replies on wine-devel, and >>> link the reply to the patch >> >> Yes. The other similar patchwatching systems I found do this, >> and ours should, too. >> >>> and mark the patch as needing further action on the submitter's >>> part. >> >> Even if the message says "Great job!"? > > Sure, that's not the usual case. In most cases when a patch gets a > reply > it's because it will need changes. There could of course be a way > for a > submitter to mark the patch as still valid, but the first action > should > be to take the patch off the list of committable patches. Perhaps replies meant to approve of a patch could include a special textual directive to indicate that patchwatcher shouldn't block the patch. Something like: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. -Ken
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
"Dan Kegel" <[EMAIL PROTECTED]> writes: > On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: >> patchwatcher should watch for replies on wine-devel, and >> link the reply to the patch > > Yes. The other similar patchwatching systems I found do this, > and ours should, too. > >> and mark the patch as needing further action on the submitter's part. > > Even if the message says "Great job!"? Sure, that's not the usual case. In most cases when a patch gets a reply it's because it will need changes. There could of course be a way for a submitter to mark the patch as still valid, but the first action should be to take the patch off the list of committable patches. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > patchwatcher should watch for replies on wine-devel, and > link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. > and mark the patch as needing further action on the submitter's part. Even if the message says "Great job!"? - Dan
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Alexandre Julliard wrote: > Kai Blin <[EMAIL PROTECTED]> writes: > >> On Monday 25 August 2008 00:06:29 Henri Verbeet wrote: >>> Something else... I sometimes reply to patches, and right now that >>> seems to cause patchwatcher to complain that my mail doesn't contain a >>> patch. Would it be possible to do something about that? >> I've got to agree with James on that one. Replies to patches should contain >> a >> patch or be to wine-devel. Patchwatcher helps to remind people on a policy >> here. This will also help people who forgot to attach a patch to their >> email, >> so I think it's a good idea to not ignore emails without patches. > > Even better patchwatcher should watch for replies on wine-devel, and > link the reply to the patch and mark the patch as needing further action > on the submitter's part. > Nice way of blocking a patch ;-). -- Cheers, Paul.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Kai Blin <[EMAIL PROTECTED]> writes: > On Monday 25 August 2008 00:06:29 Henri Verbeet wrote: >> Something else... I sometimes reply to patches, and right now that >> seems to cause patchwatcher to complain that my mail doesn't contain a >> patch. Would it be possible to do something about that? > > I've got to agree with James on that one. Replies to patches should contain a > patch or be to wine-devel. Patchwatcher helps to remind people on a policy > here. This will also help people who forgot to attach a patch to their email, > so I think it's a good idea to not ignore emails without patches. Even better patchwatcher should watch for replies on wine-devel, and link the reply to the patch and mark the patch as needing further action on the submitter's part. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 00:06:29 Henri Verbeet wrote: > Something else... I sometimes reply to patches, and right now that > seems to cause patchwatcher to complain that my mail doesn't contain a > patch. Would it be possible to do something about that? I've got to agree with James on that one. Replies to patches should contain a patch or be to wine-devel. Patchwatcher helps to remind people on a policy here. This will also help people who forgot to attach a patch to their email, so I think it's a good idea to not ignore emails without patches. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet <[EMAIL PROTECTED]> wrote: > Something else... I sometimes reply to patches, and right now that > seems to cause patchwatcher to complain that my mail doesn't contain a > patch. Would it be possible to do something about that? I suppose > patchwatcher could ignore replies without patch. > Is your reply sent to wine-patches? Any replies to a patch should be sent to wine-devel unless you're sending another patch. -- James Hawkins
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I suppose patchwatcher could ignore replies without patch.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
2008/8/24 Dan Kegel <[EMAIL PROTECTED]>: > On Sun, Aug 24, 2008 at 9:38 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: >> The script now forwards patches that pass all tests to the mailing list >> http://groups.google.com/group/wine-patches-filtered >> so potentially Alexandre could start looking only at that >> list > > Hmm. At the moment, patchwatcher will forward parts > of a patch series even if some of the series fails; > it should probably only forward a patch series if there > are no failures in any of its members. > Depends, often if a patch in a series fails the earlier patches can still be applied. Also, that a patch is part of a series doesn't necessarily mean it depends on the previous patches, sending patches as a series is just the easiest thing to do when you've got multiple patches.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Sun, Aug 24, 2008 at 9:38 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > The script now forwards patches that pass all tests to the mailing list > http://groups.google.com/group/wine-patches-filtered > so potentially Alexandre could start looking only at that > list Hmm. At the moment, patchwatcher will forward parts of a patch series even if some of the series fails; it should probably only forward a patch series if there are no failures in any of its members.
Re: Patchwatcher status
Dan Kegel wrote: > On Tue, Aug 19, 2008 at 1:35 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: >> Looks like there is something (else?) wrong with checking the patch series. >> >> None of the last patch series (by Juan, James, Rob, Stefan to name a few) >> are shown on the results page. > > Thanks for pointing that out. > It got confused by some of the debris from the earlier bug, > and was waiting for an imaginary patch to round out a series. > This is a known problem: if somebody sends a incomplete > patch series, series processing gets stuck while patchwatcher > waits for the rest of the series to show up. > The real fix will be to make get-patches.pl smarter, and handle > several overlapping patch series. Until then, I'll try adding a > timeout (say, if a patch is older than two days, I'll discard it). > - Dan > > p.s. > Rather than unswizzling the patches > mixed up by the patch series bug, I just moved the old results to > http://kegel.com/wine/patchwatcher/results.old/ > and started over. Sorry, I probably should have been more graceful about > that. > We probably need to split up results by git revision or month, > or it'll get unwieldy. Month, probably, to match the mailing list > archives? So there's probably at least one more disruption coming. > > p.p.s. > I fixed one more little bug just now: patches created > by svn should now be recognized as needing -p0. > - Dan Hi Dan, The patch series are now on the results page but every patch/test fails with these same message "d3d9:device.c:829: Test failed: Screen height is 1024" Cheers, Paul.
Re: Patchwatcher status
On Tue, Aug 19, 2008 at 1:35 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: > Looks like there is something (else?) wrong with checking the patch series. > > None of the last patch series (by Juan, James, Rob, Stefan to name a few) > are shown on the results page. Thanks for pointing that out. It got confused by some of the debris from the earlier bug, and was waiting for an imaginary patch to round out a series. This is a known problem: if somebody sends a incomplete patch series, series processing gets stuck while patchwatcher waits for the rest of the series to show up. The real fix will be to make get-patches.pl smarter, and handle several overlapping patch series. Until then, I'll try adding a timeout (say, if a patch is older than two days, I'll discard it). - Dan p.s. Rather than unswizzling the patches mixed up by the patch series bug, I just moved the old results to http://kegel.com/wine/patchwatcher/results.old/ and started over. Sorry, I probably should have been more graceful about that. We probably need to split up results by git revision or month, or it'll get unwieldy. Month, probably, to match the mailing list archives? So there's probably at least one more disruption coming. p.p.s. I fixed one more little bug just now: patches created by svn should now be recognized as needing -p0. - Dan
Re: Patchwatcher status
Dan Kegel wrote:
> Patchwatcher falsely complained that
> [2/17] richedit: Removed assumption about the order of rtf indent
> didn't apply because the regexp I used to detect
> the end of a patch series falsely matched the
> first patch in a series of 1x patches. Here's the fix:
>
> --- patchwatcher.sh (revision 150)
> +++ patchwatcher.sh (working copy)
> @@ -283,7 +283,7 @@
> cat $PATCHES/$NEXT.log
> fi
> # Use a regexp with a back reference to detect last patch in
> a series and break out
> -if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && !
> egrep -q 'Subject:.*([0-9]+)/\1' $PATCHES/$NEXT.txt
> +if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && !
> egrep -q 'Subject:.*([0-9]+)/\1[^0-9]' $PATCHES/$NEXT.txt
> then
> echo In middle of patch series, not wiping tree
> NEXT=`expr $NEXT + 1`
>
> And it falsely complained that various of [EMAIL PROTECTED]'s
> patches failed because it didn't handle the case of multiple
> patch series sent by the same author back to back and mixed
> together by email delays. Here's a fix:
>
> --- get-patches.pl (revision 150)
> +++ get-patches.pl (working copy)
> @@ -147,7 +147,7 @@
> $series_num_patches = $num_patches;
> }
>
> -if ($series_sender ne $sender) {
> +if ($series_sender ne $sender || $series_num_patches != $num_patches) {
> #print "Ignoring series for now, will try later; sender
> $sender, num_patches $num_patches, subject
> ".$header->get('Subject')."\n";
> # can't handle multiple series at once just yet, let it sit
> return;
>
> That still won't handle the case of two patch series of the same length
> being sent back to back by the same author, but that's
> ambiguous enough that even humans might be confused,
> so it should tide us over until I rewrite the patch series
> detector to handle incomplete series better.
>
> I'm on vacation so I can't apply these patches to the running instance,
> I'll do it on tuesday.
> - Dan
>
>
Hi Dan,
Looks like there is something (else?) wrong with checking the patch series.
None of the last patch series (by Juan, James, Rob, Stefan to name a
few) are shown on the results page.
Cheers,
Paul.
Re: Patchwatcher status
On Thursday 14 August 2008 16:38:40 Dan Kegel wrote: > What to do, what to do... how about this: are there any python users > on the list who would be willing to help adapt buildbot to our needs? I've subscribed to the buildbot list as well, and I'll start looking over the code once I figured out which VCS to install to get the latest greatest buildbot code. I wish people out there could just agree on which VCS is best and use git. ;) If I get the api docs right, the best option seems to be to subclass their mailwatcher to trigger the try --diff. The hardest part will be getting the patch series logic to work or possibly keeping track of the regression tests. On the plus side, it should be possible to run buildslave instances on win32, so perhaps there's a decent way to build and run the tests on win32 native right away as well. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status
On Thu, Aug 14, 2008 at 7:37 AM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > You mentioned sporadic test failures in the d3d9:visual and ddraw:visual > tests earlier, but I did not have time to look at it back then. Can you send > me logs of the failures and successes? > > I am afraid that the d3d9 failure is a driver bug; I don't know yet what is > up with the ddraw test failure Sure, I just replied in another thread about that. See also http://bugs.winehq.org/show_bug.cgi?id=10221
Re: Patchwatcher status
On Thu, Aug 14, 2008 at 2:49 AM, Darragh Bailey <[EMAIL PROTECTED]> wrote: > I currently use buildbot at work for managing builds, and it looks like > that it could handle many of your tasks if patchwatcher could be > integrated into it. Good idea. Even Mozilla, home of http://www.mozilla.org/tinderbox.html, uses it for everything but SeaMonkey: https://wiki.mozilla.org/Buildbot It looks like buildbot has a new feature (try --diff) that does almost what we want. It doesn't handle patch series, so we would have to concatenate patch series into one big patch to fit for now. They even have mailwatcher thingies, but they're for watching commit messages rather than potential patches. So we'd have to clone and mutate one of those a bit and hook it into try --diff (well, we could keep using my mailwatcher, but that wouldn't be the buildbot way). Also, its timeout is a coarse-grained one, but we also need a timeout for individual tests. That's ok, it's not hard to add into runtests. On the downside, they don't seem to have anything like the report page I have, so we'd need to add that to buildbot. What to do, what to do... how about this: are there any python users on the list who would be willing to help adapt buildbot to our needs? I don't think I can handle it alone, I'm pretty busy. Maybe I should focus on getting valgrind hooked into my existing patchwatcher while somebody else looks at buildbot. I'll join the buildbot mailing list and chat with those guys a bit to see where they think the patchwatcher functionality could fit in. - Dan
RE: Patchwatcher status
> Patchwatcher is online and giving reasonably good > feedback on the patch stream. The bug that caused > every patch to be marked 'failed tests' is fixed, and > the blacklist is expanded enough that false regressions > seem to be rare. You mentioned sporadic test failures in the d3d9:visual and ddraw:visual tests earlier, but I did not have time to look at it back then. Can you send me logs of the failures and successes? I am afraid that the d3d9 failure is a driver bug; I don't know yet what is up with the ddraw test failure
Re: Patchwatcher status
Have you considered using some of the tools out there for automated builds and looking to integrate patchwatcher to extend them to suit your purpose. A number of the features you suggest below are most likely already implemented within existing automated builds. I currently use buildbot at work for managing builds, and it looks like that it could handle many of your tasks if patchwatcher could be integrated into it. On Wed, Aug 13, 2008 at 10:42:18AM -0700, Dan Kegel wrote: > Next steps: > - add timeout to handle hanging tests (every day or two > I have to kill some test or other). There's no > portable way to do this from wine/test.h that > works in Win9x, so I'll probably set WINETEST_WRAPPER > to run the tests via a wrapper that implements the timeout. Buildbot supports configuable timeouts. > - distribute across multiple machines by splitting into master > (which watches the patch stream) and slaves (which execute tests). > I will probably use http and ftp for this so the slaves can > be remote. Also has master slave architecture, and they are also looking to support load balancing in the future. > - support multiple architectures (anybody want to run > the slaves on MacOSX for me?) Uses python for communications, so only the individual steps need to be cross platform, think configure, make depend and make. > - improve the web page to have error counts and perhaps > separate links to the build and test logs That's seems more project specific than buildbot, but who knows, it might be implementable in a generic way to suit buildbot. > - merge the chroot support (though this will need porting to > run on MacOSX) Would have to be added as a custom step > - add valgrind as the next step after running tests Supports individual steps > - improve the web page generator to show current status > (e.g. show the results from "make test" before starting valgrind) Generates separate logs for each step website is: http://buildbot.net/trac -- Darragh "Nothing is foolproof to a sufficiently talented fool."
