I'm just sending this out as a reminder for everyone to book your hotel room for WineConf. For more information, check out:
1. http://www.winehq.com/site/wineconf 2. http://www.winehq.com/site/wineconf/travel
The last day to reserve a room is tomorrow - March 17th. There's no guarantee rooms will be available after that, and I don't have any indication the hotel will allow reservations after that. If you haven't looked at the details, it's a great deal - 81EUR for Friday and Saturday night and it includes breakfast in the morning.
If you're thinking to yourself, "I'd like to go to Wineconf, but I don't think I'm cool enough." Well, you should try to attend. You'll probably really enjoy it.
PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something.
-Brian
Brian Vincent wrote:
I PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something.
Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test.
Maybe we can extend on the winetest.exe infrastructure. I would like to see testing done in realtime - we now have a turnaround of maybe 3-4 days for a test developer like myself. I do a tiny, tiny patch, and then wait 3-4 days to see how it behaves on 6 platforms.
What I would like to see: a "cluster" of Windows machines with different versions, all waiting eagerly for a small test.exe to appear. A dispatcher receives tests and then distributes it to waiting Windows machines. As soon as machine has run a test, it is rebooted. Preferrably from a clean vmware image.
Mockup example:
jakov@black:~/src/wine/dlls/kernel/tests$ make testgrid_file i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.cross.o file.c file.c:1: warning: -fPIC ignored for target (all code is position independent) i586-mingw32msvc-gcc alloc.cross.o atom.cross.o change.cross.o codepage.cross.o comm.cross.o console.cross.o directory.cross.o drive.cross.o environ.cross.o file.cross.o format_msg.cross.o generated.cross.o heap.cross.o locale.cross.o module.cross.o mailslot.cross.o path.cross.o pipe.cross.o process.cross.o profile.cross.o thread.cross.o time.cross.o timer.cross.o virtual.cross.o testlist.cross.o -o kernel32_crosstest.exe -lkernel32 i586-mingw32msvc-strip kernel32_crosstest.exe upx kernel32_crosstest.exe gpg --sign kernel32_crosstest.exe > kernel32_crosstest.sig tar -cf kernel32_crosstest.tar kernel32_crosstest.exe kernel32_crosstest.sig wget http://testgrid.winehq.org/gridtest.cgi --post-file=kernel32_crosstest.tar --output-document=testgrid_file.txt jakov@black:~/src/wine/dlls/kernel/tests$ jakov@black:~/src/wine/dlls/kernel/tests$ jakov@black:~/src/wine/dlls/kernel/tests$ cat testgrid_file.txt Windows 2000 begin: file.c:1384: Test failed: DeleteFileA: error 3 file: 487732 tests executed, 0 marked as todo, 1 failure. End Windows 2000. Windows 98 begin: file.c:804: Test failed: MoveFileA: unexpected error 3 file.c:1384: Test failed: DeleteFileA: error 3 file: 487732 tests executed, 0 marked as todo, 2 failures. End Windows 98. Windows XP begin: file: 487732 tests executed, 0 marked as todo, 0 failures. End Windows XP. Windows NT4 begin: file: 487732 tests executed, 0 marked as todo, 0 failures. End Windows NT4. jakov@black:~/src/wine/dlls/kernel/tests$ jakov@black:~/src/wine/dlls/kernel/tests$ jakov@black:~/src/wine/dlls/kernel/tests$
regards, Jakob
On Thursday 17 March 2005 10:33, Jakob Eriksson wrote:
Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test.
Yes, although that's a rather weary job, which no one enjoys doing :^/
Maybe we can extend on the winetest.exe infrastructure. I would like to see testing done in realtime [...]
There's three issues here:
o fast(er) update of CVS (or whatever filestore we're using).
This would need either: * a super-charged Alexandre ;) or * a separate CVS tree in which developers can edit the wine/dlls/*/tests/ directory, or * give up on centralised/distributed testing architecture and switch to a personal testing environment.
o fast(er) build of winetest.exe
I originally argued for async. winetests and went as far as implementing this as part of WRT, so in principles this is already done. WRT worked based on the email notification of CVS updates. Builds, with minor changes, doesn't take long (using ccache), so you're probably looking 10-20 minutes turn around, with whatever delay the test-clients introduce.
Though, without fixing the first issue, this doesn't help us much.
o fast(er) running, through vmware platforms.
Sure, this can be done, but its a distributed model, so everyone can chip in. Shouldn't be too difficult to achieve this.
Just my 2-c worth :)
Paul.
Paul Millar wrote:
On Thursday 17 March 2005 10:33, Jakob Eriksson wrote:
Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test.
Yes, although that's a rather weary job, which no one enjoys doing :^/
I do! Maybe I have a condition, but I really love doing it! :-)
There's three issues here:
Yes.
o fast(er) update of CVS (or whatever filestore we're using).
This would need either: * a super-charged Alexandre ;) or * a separate CVS tree in which developers can edit the wine/dlls/*/tests/ directory,
This makes sense. Winetest could actually be a separate project. I'm not saying it should be, mind you, just that conformance testing is interesting not only for Wine, but for Windows developers in general.
So a separate CVS tree makes a great deal of sense, IMHO. Wine could import snapshots of the tests for its' conformance testing. This could speed up test development considerably, I imagine.
or * give up on centralised/distributed testing architecture and switch to a personal testing environment.
o fast(er) build of winetest.exe
I originally argued for async. winetests and went as far as implementing this as part of WRT, so in principles this is already done. WRT worked based on the email notification of CVS updates. Builds, with minor changes, doesn't take long (using ccache), so you're probably looking 10-20 minutes turn around, with whatever delay the test-clients introduce.
Though, without fixing the first issue, this doesn't help us much.
o fast(er) running, through vmware platforms.
Sure, this can be done, but its a distributed model, so everyone can chip in. Shouldn't be too difficult to achieve this.
Sounds like fun, doesn't it? Test servers could register in the cluster worldwide. (Although I originally imagined a very centralized solution with a big server running vmware images.)
Just my 2-c worth :)
Are you coming to wineconf?
regards, Jakob
On Thursday 17 March 2005 11:51, Jakob Eriksson wrote:
Paul Millar wrote:
[writing tests]'s a rather weary job, which no one enjoys doing :^/
I do! Maybe I have a condition, but I really love doing it! :-)
Long may that continue!
[...]
[separate CVS tree]
This makes sense. Winetest could actually be a separate project. I'm not saying it should be, mind you, just that conformance testing is interesting not only for Wine, but for Windows developers in general.
So a separate CVS tree makes a great deal of sense, IMHO. Wine could import snapshots of the tests for its' conformance testing. This could speed up test development considerably, I imagine.
I'd tread careful here: this isn't a panacea.
Yes, its fairly easy to *say* OK, we just merge in the new tests, but would merging the snapshots really be a trivial job? If it is non-trivial, then Alexandre would front at least some of it and I suspect making more work for Alexandre is the last thing anyone (including Alexandre :^) would want.
On top of that, there would be many other issues, e.g. How the diffs between the two trees were presented? How the changes in wine would be merged back into the winetest tree? What happens to patches that Alexandre rejects (coz they're just wrong)?
Ultimately, its Alexandre's call (and I think I can guess his answer).
[...]
Are you coming to wineconf?
All things being equal, yes.
Cheers,
Paul.
Brian Vincent wrote:
PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something.
Will anyone demo CXtest? I think it would be great.
regards, Jakob
Will anyone demo CXtest? I think it would be great.
I think that's one of those topics that Brian is holding in reserve; we'll be more than happy to demo it.
Jer
Hi,
On Thu, Mar 17, 2005 at 08:35:25AM -0600, Jeremy White wrote:
Will anyone demo CXtest? I think it would be great.
I think that's one of those topics that Brian is holding in reserve; we'll be more than happy to demo it.
Nice stuff!
Will you have decided by then whether to call it CXtest, Cxtest, CxTest or CXTEST? ;-) (YES, I've seen all of those!)
Andreas
Andreas Mohr wrote:
Hi,
On Thu, Mar 17, 2005 at 08:35:25AM -0600, Jeremy White wrote:
Will anyone demo CXtest? I think it would be great.
I think that's one of those topics that Brian is holding in reserve; we'll be more than happy to demo it.
Nice stuff!
Will you have decided by then whether to call it CXtest, Cxtest, CxTest or CXTEST? ;-) (YES, I've seen all of those!)
Andreas
The logo on the website is CXtest.
-
Andreas Mohr -
Brian Vincent -
Jakob Eriksson -
Jeremy White -
Paul Millar