Seth Shelnutt wrote:
I am wondering what that status of patchwatcher is?
It's waiting around for somebody to have time to start it up again. It's ugly code, written in shell and perl, which scares most people off. One has to wonder whether it shouldn't be done over again using buildbot, just to avoid scaring people. But it could live on in its present form given time and attention. Another problem is that the code for watching for patch series is fragile. We might conceivably move to driving it from a web submission form like WineTestBot uses, that would solve that.
(I've been focusing my precious Wine time on the daily valgrind runs. It would be cool to run those tests on Patchwatcher; that was the whole goal of patchwatcher, actually. I think to do it fast enough we'd have to take a shortcut, like only valgrind the tests most obviously related to the change.)
I saw the ideals for converting UnitTestSuit and wpkg scripts to Appinstall. I definitely think this is a good idea and needed; however I was thinking that linking patchwatcher and appinstall testing would be even more beneficial.
You're referring to http://wiki.winehq.org/SummerOfCode#head-6e93309cf25ab1bb55e35698562cac148d8... and http://wiki.winehq.org/UnitTestSuites
A daily run of appinstall is probably sufficient. Austin does that already. The main downside is that the results aren't tied in to test.winehq.org.
It'd be really great to invoke lots of wpkg installs from inside Appinstall, and file bugs for whatever that turns up. (And fix them, maybe.)
UnitTestSuites is a bit more programmer-oriented. I'd recommend that if you're interested in becoming a developer. Grinding through and automating builds for a few open source apps on wine would probably teach you a lot. - Dan
Just some ideas by me:
Dan Kegel schrieb:
Seth Shelnutt wrote:
I am wondering what that status of patchwatcher is?
It's waiting around for somebody to have time to start it up again. It's ugly code, written in shell and perl, which scares most people off. One has to wonder whether it shouldn't be done over again using buildbot, just to avoid scaring people. But it could live on in its present form given time and attention. Another problem is that the code for watching for patch series is fragile. We might conceivably move to driving it from a web submission form like WineTestBot uses, that would solve that.
maybe we can merge patchwatcher with http://source.winehq.org/patches/ or let it just parse it and let patchwatcher run on an extra winetestbot machine??
2010/2/16 André Hentschel nerv@dawncrow.de
Just some ideas by me:
Dan Kegel schrieb:
Seth Shelnutt wrote:
I am wondering what that status of patchwatcher is?
It's waiting around for somebody to have time to start it up again. It's ugly code, written in shell and perl, which scares most people off. One has to wonder whether it shouldn't be done over again using buildbot, just to avoid scaring people. But it could live on in its present form given time and attention. Another problem is that the code for watching for patch series is fragile. We might conceivably move to driving it from a web submission form like WineTestBot uses, that would solve that.
maybe we can merge patchwatcher with http://source.winehq.org/patches/ or let it just parse it and let patchwatcher run on an extra winetestbot machine??
Well in that case then, perhaps an entire GSoC project could be devoted to patchwatcher and getting it running again? I would be interested in doing such a thing. I will download the code from your google site (I assume that is the latest code?), and start having some fun with it to get myself acquainted.
Thanks,
Seth Shelnutt
On 2/17/2010 23:32, Seth Shelnutt wrote:
2010/2/16 André Hentschel <nerv@dawncrow.de mailto:nerv@dawncrow.de>
Just some ideas by me: Dan Kegel schrieb: > Seth Shelnutt wrote: >> I am wondering what that status of patchwatcher is? > > It's waiting around for somebody to have time to start it > up again. It's ugly code, written in shell and perl, which > scares most people off. One has to wonder whether it > shouldn't be done over again using buildbot, just to avoid > scaring people. But it could live on in its present form > given time and attention. Another problem is that the > code for watching for patch series is fragile. We might > conceivably move to driving it from a web submission form > like WineTestBot uses, that would solve that. maybe we can merge patchwatcher with http://source.winehq.org/patches/ or let it just parse it and let patchwatcher run on an extra winetestbot machine??Well in that case then, perhaps an entire GSoC project could be devoted to patchwatcher and getting it running again? I would be interested in doing such a thing. I will download the code from your google site (I assume that is the latest code?), and start having some fun with it to get myself acquainted.
Personally I don't think patchwatcher deserves this. I mean if Wine has a student limit there's a lot of unimplemented things and bugs that are more important. It's nice to have such service, but it's not critical with daily updated test runs that already work. Possible GSoC project that is really needed and is very important is extending Wine builtin test suite. It could focus on selected components or components and bugzilla reports with 'testcase' keyword, there's a lot of option. Also it's useful to improve existing tests, and I mean structure too. A lot of tests for msxml for example (I'm currently working on) should be table driven, and are hard to read in some cases now. First thing to be done outside working code itself is improving tests, imho of course.
Thanks.
Thanks,
Seth Shelnutt
-
André Hentschel -
Dan Kegel -
Nikolay Sivov -
Seth Shelnutt