Hi everyone,
I just got back from sunny San Diego last night to not-so-sunny Ottawa, where I seem to have been just in time to catch a snow storm, lucky me!
As I said I would do at the conference, I am posting notes on the road to Wine 0.9 (tasks that Alexandre requires to consider WINE at the 0.9 stage), and the names of the people who volunteered to get the ball rolling on each point.
For Wine 0.9 ========= * Dll seperation (being able to build on windows being a "Wish") - Dimi, Patrick, Steven, Alexandre, Scott * Address Space Seperation - Alexandre * Window Management - Ulrich, Mike, Alexandre * Wine Server Protocols (DONE) * Regression Testing - Francois, Andridy, Patrick, Dimi, Andi, Steven * Documention -> Call for a FAQ maintainer Urivan, Andi, Jeremy Newman * Bugzilla - Francois, Andridy, Jeremy Newman- to create a wine-bug maillist ALL should commit to using bugbase
The other keypoint that was brought up was that: we need to drive users in and make it easy for them to help with (A) Docs, (B) Bugs, and (C) Testing apps
-James
- Wine Server Protocols (DONE)
it this really done ? I still have some enhancements - one has already be sent for improving toolhelp process snapshots (btw, Alexandre didn't commit it yet, even if two versions of it have been provided - the second by Andi -. Is this related ?) - CreateProcess still missing a few parameters being passed around (mostly done, but still need some ironing out) - among the things I'd like to at least settle down on the protocol level is the console inheriting unix fd:s for the unix console this is currently rather badly supported, and my wish would be to have it right for 1.0
A+
- Wine Server Protocols (DONE)
it this really done ? I still have some enhancements
I think you better send an email to Alexandre then, because he said at the conference that "it (Wineserver protocol) is basically finished, we just need to formally freeze it" (or something like that, that is not a word for word quote)
-James
On Tue, Mar 19, 2002 at 10:09:59AM -0500, James Hatheway wrote:
- Wine Server Protocols (DONE)
it this really done ? I still have some enhancements
I think you better send an email to Alexandre then, because he said at the conference that "it (Wineserver protocol) is basically finished, we just need to formally freeze it" (or something like that, that is not a word for word quote)
Yep.
In fact I raised my eyebrows on that statement of him, too.
There's probably a lot of NT object stuff that's not 150% implemented yet, I think. And if the wineserver protocol isn't independent from such changes (I dunno about that), then it certainly can't be considered truly "stable".
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
In fact I raised my eyebrows on that statement of him, too.
There's probably a lot of NT object stuff that's not 150% implemented yet, I think. And if the wineserver protocol isn't independent from such changes (I dunno about that), then it certainly can't be considered truly "stable".
The point is not to freeze the protocol completely, it will clearly continue to evolve even after 1.0. The idea is that once the protocol is declared frozen all future changes are done in a way that preserves backwards compatibility. And the mechanisms to do that are mostly in place now, which is what I mean by saying it is finished.
On Tue, Mar 19, 2002 at 09:22:42AM -0800, Alexandre Julliard wrote:
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
In fact I raised my eyebrows on that statement of him, too.
There's probably a lot of NT object stuff that's not 150% implemented yet, I think. And if the wineserver protocol isn't independent from such changes (I dunno about that), then it certainly can't be considered truly "stable".
The point is not to freeze the protocol completely, it will clearly continue to evolve even after 1.0. The idea is that once the protocol is declared frozen all future changes are done in a way that preserves backwards compatibility. And the mechanisms to do that are mostly in place now, which is what I mean by saying it is finished.
OK, so in other words the wineserver *is* more or less "independent from such changes".
That's nice to know :)
On March 19, 2002 12:48 pm, Andreas Mohr wrote:
The point is not to freeze the protocol completely, it will clearly continue to evolve even after 1.0. The idea is that once the protocol is declared frozen all future changes are done in a way that preserves backwards compatibility. And the mechanisms to do that are mostly in place now, which is what I mean by saying it is finished.
OK, so in other words the wineserver *is* more or less "independent from such changes".
How can that be? What we want is that DLLs compiled with 1.x, work (at the binary level) with any 1.y server, where x <= y, right?
Alexandre Julliard a écrit :
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
In fact I raised my eyebrows on that statement of him, too.
There's probably a lot of NT object stuff that's not 150% implemented yet, I think. And if the wineserver protocol isn't independent from such changes (I dunno about that), then it certainly can't be considered truly "stable".
The point is not to freeze the protocol completely, it will clearly continue to evolve even after 1.0. The idea is that once the protocol is declared frozen all future changes are done in a way that preserves backwards compatibility. And the mechanisms to do that are mostly in place now, which is what I mean by saying it is finished.
that's why I think we should clearly look at it now... what bugs me is the server request which only partially implement a feature so, if we freeze them now, we'll have to add another request, which will be a subset of the existing one in order to prevent too much code bloat in this area, this should be reviewed rather carefully. it doesn't mean we have to implement all the features, it means we need to pass most of the information (when possible)
(I particulary have in mind the CreateProcess API)
A+
Eric Pouech eric.pouech@wanadoo.fr writes:
that's why I think we should clearly look at it now... what bugs me is the server request which only partially implement a feature so, if we freeze them now, we'll have to add another request, which will be a subset of the existing one in order to prevent too much code bloat in this area, this should be reviewed rather carefully. it doesn't mean we have to implement all the features, it means we need to pass most of the information (when possible)
It's OK to add fields to existing requests, this doesn't break backwards compatibility. In fact that's one of the reasons for the fixed request size. So as long as there is still some room in the request buffer it's not a problem (and yes CreateProcess is an exception, and will be fixed before the protocol is really frozen).
It's OK to add fields to existing requests, this doesn't break backwards compatibility. In fact that's one of the reasons for the fixed request size.
and you can tell which fields are valid from the protocol version number I assume
another point: as of today, at startup, the link to wineserver isn't done when the protocol version doesn't match... so, it seems you'll be removing this test after the protocol freeze (or at least that the protocol version returned in init_thread is greater the frozen protocol version)
A+
PS: any answer on the reasons for not applying the toolhelp patch?
Eric Pouech eric.pouech@wanadoo.fr writes:
and you can tell which fields are valid from the protocol version number I assume
The missing fields are filled with zero so we shouldn't even need that.
another point: as of today, at startup, the link to wineserver isn't done when the protocol version doesn't match... so, it seems you'll be removing this test after the protocol freeze (or at least that the protocol version returned in init_thread is greater the frozen protocol version)
Yes.
PS: any answer on the reasons for not applying the toolhelp patch?
Working on it...
James Hatheway wrote:
Hi everyone,
[Snip]
The other keypoint that was brought up was that: we need to drive
users in and make it easy
for them to help with (A) Docs, (B) Bugs, and (C) Testing apps
-James
As a _not_to_bright_ user of wine I would like to comment on the above.
A) Thankyou to Jerry Newman for getting the online documentation at winehq current this I feel is the first/best step to getting user input to the docs. By keeping the documentation at winehq current users (like me) can count on having access to the most current documentation without additional searching. To build on this we need a documentation mailing list to capture/discuss problems with the documentation. I believe it would be helpfull to have a link to this list via www.winehq.com/support.shtml . This would enable users to easily contribute thier comments. Of course having the network news interface up and running would be helpfull as well (insert smilely).
B) My thoughts on bugs. all Bugs fall into four categories
1. Crashes Crashes are relitively easy to find and report. The documentation for this just needs to point to bugzilla for reporting.
2. Regressions (function used to work and now dosn't) These bugs are a little harder to trace but the procedure is well documented. We need get the reporting of these bugs to point to bugzilla.
3. FIXME's (function is not implimented) There should be a bugzilla report for each FIXME.
4. Incorrect implimentation bugs These are bugs that are hard to find/fix because the function is implimented incorrectly but the program works otherwise. There isn't any really good documentation on how to track these types of bugs (that I could find).
All that is fine enough and can be fixed through proper documentation.
Bugzilla however needs considerable work in order for it to be usefull. in order to get this email out in a timely fashion I can't be more specific. I will comment on the problems I see with bugzilla at a latter date. I do think we should use it but it needs work.
C. Testing apps? I have no real idea what you mean.
Tony Lambregts
C. Testing apps? I have no real idea what you mean.
Sorry, I guess I should have been more clear, I just typed in word for word my brief shorthand notes :)
Basically, the idea that we had was the concept of getting users to volunteer to "own" an app, ie. responsible for yelling when we break an app. This already sort of happens, but never in a formal way. We never decided the details, but I envisiage having one person volunteering to each test their favourite app on every release and filing bugs. (in a way that is helpful, we'll have docs for that)
-James
The specific goal was to clone Lawson 50 times, and have each clone pick up an application.
<grin>
On Tue, 2002-03-19 at 09:14, James Hatheway wrote:
C. Testing apps? I have no real idea what you mean.
Sorry, I guess I should have been more clear, I just typed in word for word my brief shorthand notes :)
Basically, the idea that we had was the concept of getting users to volunteer to "own" an app, ie. responsible for yelling when we break an app. This already sort of happens, but never in a formal way. We never decided the details, but I envisiage having one person volunteering to each test their favourite app on every release and filing bugs. (in a way that is helpful, we'll have docs for that)
-James
-- James Hatheway james@macadamian.com ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies.
Obligatory Geek Expression: "Save the Whales, Free the mallocs!"
On Tuesday 19 March 2002 16:14, James Hatheway wrote:
C. Testing apps? I have no real idea what you mean.
Sorry, I guess I should have been more clear, I just typed in word for word my brief shorthand notes :)
Basically, the idea that we had was the concept of getting users to volunteer to "own" an app, ie. responsible for yelling when we break an app. This already sort of happens, but never in a formal way. We never decided the details, but I envisiage having one person volunteering to each test their favourite app on every release and filing bugs. (in a way that is helpful, we'll have docs for that)
I think this is a great idea. I find it almost unbelievable how well the only two applications that I really miss (soundforge and samplitute) work with wine (_much_ better than with vmware!), and I would happily step forward to "maintain" them for the wine project. cheers, Yven
P.S: thanks for all the great work!
Can you pick up wine and compile it on a daily/weekly basis and let us know when/if your apps break?
Yven Leist wrote:
On Tuesday 19 March 2002 16:14, James Hatheway wrote:
C. Testing apps? I have no real idea what you mean.
Sorry, I guess I should have been more clear, I just typed in word for word my brief shorthand notes :)
Basically, the idea that we had was the concept of getting users to volunteer to "own" an app, ie. responsible for yelling when we break an app. This already sort of happens, but never in a formal way. We never decided the details, but I envisiage having one person volunteering to each test their favourite app on every release and filing bugs. (in a way that is helpful, we'll have docs for that)
I think this is a great idea. I find it almost unbelievable how well the only two applications that I really miss (soundforge and samplitute) work with wine (_much_ better than with vmware!), and I would happily step forward to "maintain" them for the wine project. cheers, Yven
P.S: thanks for all the great work!
On Tuesday 19 March 2002 23:47, Michael Cardenas wrote:
Can you pick up wine and compile it on a daily/weekly basis and let us know when/if your apps break?
Yes, definitely. I might not be able to do it _every_ day, but I could certainly guarantee testing it at least once a week. As far as trivial breakage is concerned (i.e application not starting at all) I could probably even setup a simple cron job on my server that does a "cvs up -dP && configure && make && make install && wine {my appp}" and tests whether the application comes up, notifying me if it doesn't. cheers, Yven
On Wed, 20 Mar 2002, Yven Leist wrote:
On Tuesday 19 March 2002 23:47, Michael Cardenas wrote:
Can you pick up wine and compile it on a daily/weekly basis and let us know when/if your apps break?
Yes, definitely. I might not be able to do it _every_ day, but I could certainly guarantee testing it at least once a week. As far as trivial breakage is concerned (i.e application not starting at all) I could probably even setup a simple cron job on my server that does a "cvs up -dP && configure && make && make install && wine {my appp}" and tests whether the application comes up, notifying me if it doesn't.
I think that doing it each time Alexandre releases a new version of Wine (about every two weeks) would even be enough... at least until we reach 0.9. Then we would want to know about breakage during or before the -betaX/-preX phase. But if you can do it weekly it's even better. It's just that I don't want to scare other volunteers who may think we expect them to test their applications with a new Wine every day :-)
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
The problem with only testing releases is that so many patches go into a release, that you won't know what patch broke your app.
I think the real problem is, what would your cron job do after the "wine {my app}" stage?
how about doing a
"wine {my app} > myapp.log && tail -f myapp.log | grep 'segfault occurred' && mail me@mydomain.com "my app crashed" ^D^D^D
or some such thing in a more robust script? I know the above syntax won't work, but basically, check the output of the app and look for some kind of crash condition, and mail yourself if it occurs.
Francois Gouget wrote:
I could probably even setup a simple cron job on my server that does a "cvs up -dP && configure && make && make install && wine {my appp}" and tests whether the application comes up, notifying me if it doesn't.
I think that doing it each time Alexandre releases a new version of Wine (about every two weeks) would even be enough... at least until we reach 0.9. Then we would want to know about breakage during or before the -betaX/-preX phase. But if you can do it weekly it's even better. It's just that I don't want to scare other volunteers who may think we expect them to test their applications with a new Wine every day :-)
On Tue, 19 Mar 2002, Michael Cardenas wrote:
The problem with only testing releases is that so many patches go into a release, that you won't know what patch broke your app.
Well, you only have about two weeks worth of patches to check. It's already better than the current situation where applications are not tested on a regular basis so that when a bug is reported there may be months of patches to check out.
I think the real problem is, what would your cron job do after the "wine {my app}" stage?
how about doing a
"wine {my app} > myapp.log && tail -f myapp.log | grep 'segfault occurred' && mail me@mydomain.com "my app crashed" ^D^D^D
The problem is that if the application does not crash it is likely to stay up indefinitely waiting for you to do something... Rather than automating the testing, it may be better to automate the process of updating Wine. This can be done completely unattended and can thus be done daily. Maybe a procedure documenting how to do this would be useful. Then as soon as Wine breaks something the user will know about it, just by using the application for normal stuff. Add to this a weekly check to see if any of the known bugs has been fixed, update the Application database entry if that's the case, and we have something which I think is close to ideal. Of course it would be wise to keep a known good Wine release in store in case Wine does break stuff.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Francois Gouget wrote:
On Tue, 19 Mar 2002, Michael Cardenas wrote:
The problem is that if the application does not crash it is likely to stay up indefinitely waiting for you to do something... Rather than automating the testing, it may be better to automate the process of updating Wine. This can be done completely unattended and can thus be done daily. Maybe a procedure documenting how to do this would be useful.
While I think this is a great idea for people who use their apps every day, it still depends on having a bunch of testers.
It would be trivial to have your script killall wine after 5 minutes of it sitting there waiting for you. My main concern was that a seg fault doesn't necessarily mean that the app will terminate. Also, this only checks that apps can launch, not that they are functional in any way. A combination of both approaches would be helpful.
Hello Michael, At wineconf Michael Robertson said that everyone would be registered as lindows developers so we could get access to the preview releases. What do we have to do to get registered.
Thanks Steven
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Wednesday 20 March 2002 02:12, you wrote:
The problem with only testing releases is that so many patches go into a release, that you won't know what patch broke your app.
I think the real problem is, what would your cron job do after the "wine {my app}" stage?
how about doing a
"wine {my app} > myapp.log && tail -f myapp.log | grep 'segfault occurred' && mail me@mydomain.com "my app crashed" ^D^D^D
or some such thing in a more robust script? I know the above syntax won't work, but basically, check the output of the app and look for some kind of crash condition, and mail yourself if it occurs.
yes, that's exactly what I had in mind, it was implied in the "notifying me if it doesn't" part :-) checking for "Unhandled exception" or for instance deadlock stuff like "err:ntdll:RtlpWaitForCriticalSection..." in the log file should be trivial. But that's probably not going to happen that often anyway, and of course it's not meant as a substitute for "real world" tests, rather as a "zero cost" additional check. cheers, Yven
Well, that's great. If you do write the script, please post it here for others to use. If I write it, I'll do the same.
Yven Leist wrote:
On Wednesday 20 March 2002 02:12, you wrote:
The problem with only testing releases is that so many patches go into a release, that you won't know what patch broke your app.
I think the real problem is, what would your cron job do after the "wine {my app}" stage?
how about doing a
"wine {my app} > myapp.log && tail -f myapp.log | grep 'segfault occurred' && mail me@mydomain.com "my app crashed" ^D^D^D
or some such thing in a more robust script? I know the above syntax won't work, but basically, check the output of the app and look for some kind of crash condition, and mail yourself if it occurs.
yes, that's exactly what I had in mind, it was implied in the "notifying me if it doesn't" part :-) checking for "Unhandled exception" or for instance deadlock stuff like "err:ntdll:RtlpWaitForCriticalSection..." in the log file should be trivial. But that's probably not going to happen that often anyway, and of course it's not meant as a substitute for "real world" tests, rather as a "zero cost" additional check. cheers, Yven
On Wednesday 20 March 2002 18:56, you wrote:
Well, that's great. If you do write the script, please post it here for others to use. If I write it, I'll do the same.
something like this might be enough:
#!/bin/bash
WINECVS="/usr/src/wine" CONFOPTS="--prefix=/usr" WINEOPTS="" TESTAPPS="app1 app2" FAILSTRINGS="Unhandled.*exception err:ntdll:RtlpWaitForCriticalSection" MAILTO="you@yourdomain.com"
# make sure we have the latest stuff.. cd $WINECVS && cvs -z3 up -dP && configure $CONFOPTS && make && make install
for app in $TESTAPPS; do wine $WINEOPTS $app > $app.log & sleep 360 # starting the app might take some time.. for string in $FAILSTRINGS; do if [ $(grep -i -c -e "$string" $app.log) != 0 ]; then # maybe we want a diff against the old log.. if [ "$1" = "-d" ]; then echo -e "\n\tdiff against old logfile\n" >> $app.log diff -u $app.log $app.old >> $app.log fi cat $app.log | mail -s "wine problems running $app" $MAILTO cp $app.log $app.old killall wine fi done; done;
cheers, Yven
This looks awesome. I can set up a machine that tests the Office 2000 apps on a daily basis with this.
I'm wondering about your failstrings though. Will wine with no debugmsg's print that line? Won't it just print "Seg Fault Occurred" ?
Yven Leist wrote:
On Wednesday 20 March 2002 18:56, you wrote:
Well, that's great. If you do write the script, please post it here for others to use. If I write it, I'll do the same.
something like this might be enough:
#!/bin/bash
WINECVS="/usr/src/wine" CONFOPTS="--prefix=/usr" WINEOPTS="" TESTAPPS="app1 app2" FAILSTRINGS="Unhandled.*exception err:ntdll:RtlpWaitForCriticalSection" MAILTO="you@yourdomain.com"
# make sure we have the latest stuff.. cd $WINECVS && cvs -z3 up -dP && configure $CONFOPTS && make && make install
for app in $TESTAPPS; do wine $WINEOPTS $app > $app.log & sleep 360 # starting the app might take some time.. for string in $FAILSTRINGS; do if [ $(grep -i -c -e "$string" $app.log) != 0 ]; then # maybe we want a diff against the old log.. if [ "$1" = "-d" ]; then echo -e "\n\tdiff against old logfile\n" >> $app.log diff -u $app.log $app.old >> $app.log fi cat $app.log | mail -s "wine problems running $app" $MAILTO cp $app.log $app.old killall wine fi done; done;
cheers, Yven
On Thursday 21 March 2002 02:21, you wrote:
This looks awesome. I can set up a machine that tests the Office 2000 apps on a daily basis with this.
I'm wondering about your failstrings though. Will wine with no debugmsg's print that line? Won't it just print "Seg Fault Occurred" ?
At least it doesn't do so for me, and I could not find any special debug options or the like in my wine config, I thought that it was the default to get all "err:" and "fixmes:" to standard out, and providing --debugmsg +something was only necessary if you wanted to get special debug messages. cheers, Yven
--- Francois Gouget fgouget@free.fr wrote:
On Wed, 20 Mar 2002, Yven Leist wrote:
On Tuesday 19 March 2002 23:47, Michael Cardenas
wrote:
Can you pick up wine and compile it on a
daily/weekly basis and let us
know when/if your apps break?
Yes, definitely. I might not be able to do it
_every_ day, but I could
certainly guarantee testing it at least once a
week.
As far as trivial breakage is concerned (i.e
application not starting at all)
I could probably even setup a simple cron job on
my server that does a
"cvs up -dP && configure && make && make install
&& wine {my appp}"
and tests whether the application comes up,
notifying me if it doesn't.
I think that doing it each time Alexandre releases a new version of Wine (about every two weeks) would even be enough... at least until we reach 0.9.
Agree with Francois - testing once in two weeks will be enough.
Yven, could you put information about the application to the Application Database (http://wine.codeweavers.com/appdb/)? It would be also great if you could maintain information about these applications there, put nice screenshots, detailed description etc. This won't take a lot of your time, but it is a great help to the Wine image to have 2 more applications with rating "works perfectly" in the application database.
Andriy Palamarchuk
__________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
Yven, could you put information about the application to the Application Database (http://wine.codeweavers.com/appdb/)? It would be also great if you could maintain information about these applications there, put nice screenshots, detailed description etc. This won't take a lot of your time, but it is a great help to the Wine image to have 2 more applications with rating "works perfectly" in the application database.
As a side note, the design for the app db called for a 'maintainer' field. The thought was that people trying to use that app could (possibly) email the maintainer. Sort of a live discussion/support area for each app. Hmm. Maybe just email each new comment posted to the maintainer rather than encourage email flooding.
The further thought was that with each new release cut, there could be a 'sounding off' process, whereby each registered maintainer would validate that the new release worked with their app. A user of the app db could then see a list of 'verified' Wine releases.
We didn't really have a clear vision of exactly what was necessary, but Jer (Newman, that is) is very good at tweaking that stuff, so if others have better ideas, fire away.
Of course, Jer has a mile high pile of *other* things he has to get done first...<g>
Jer
On Wednesday 20 March 2002 15:04, you wrote:
--- Francois Gouget fgouget@free.fr wrote:
On Wed, 20 Mar 2002, Yven Leist wrote:
On Tuesday 19 March 2002 23:47, Michael Cardenas
wrote:
Can you pick up wine and compile it on a
[...]
I think that doing it each time Alexandre releases a new version of Wine (about every two weeks) would even be enough... at least until we reach 0.9.
Agree with Francois - testing once in two weeks will be enough.
Yven, could you put information about the application to the Application Database (http://wine.codeweavers.com/appdb/)? It would be also great if you could maintain information about these applications there, put nice screenshots, detailed description etc. This won't take a lot of your time, but it is a great help to the Wine image to have 2 more applications with rating "works perfectly" in the application database.
Yes, I will do that, I already wanted to do this some time ago, but then never got around to actually doing it. The only remaining problem is that I do not have valid licenses for these two applications... I know it's kind of stupid to say something like this on a public mailing list, and maybe the next email I'll get has "our piracy department wants to talk to you" in the subject line, but to be honest I really do not feel guilty about this, since I never used these applications in any kind of production environment, and personal use should always be free of charge IMO, just the way it already is with many applications like jbuilder, staroffice, DB2 etc.
<hint> If the companies producing these two applications actively supported linux, for instance by making sure that their applications really worked perfectly with wine I would not hesitate to buy a copy of them, even though that would stress my financial budget as a student quite a bit. </hint> ... well, probably none of these companies are ever going to actually read this, which is almost sad, but actively contacting them saying "thanks to some cracker group I'm tinkering with your software for free, and if you had a linux version, I would even pay for it", seems just a bit too drastic ;-) cheers, Yven
--- James Hatheway james@macadamian.com wrote:
For Wine 0.9
- Dll seperation (being able to build on windows
being a "Wish") - Dimi, Patrick, Steven, Alexandre, Scott
- Address Space Seperation - Alexandre
- Window Management - Ulrich, Mike, Alexandre
- Wine Server Protocols (DONE)
- Regression Testing - Francois, Andridy, Patrick,
Dimi, Andi, Steven
Hmm, Regression Tests development will never finish. Can you define any specific goal for the regression tests you want to accomplish for 0.9?
- Documention -> Call for a FAQ maintainer Urivan, Andi, Jeremy Newman
- Bugzilla - Francois, Andridy, Jeremy Newman- to
create a wine-bug maillist ALL should commit to using bugbase
We should create a (meta?) bug for each task, and make bug "Wine 0.9" depend on these bugs.
Andriy Palamarchuk
__________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
- Regression Testing - Francois, Andridy, Patrick,
Dimi, Andi, Steven
Hmm, Regression Tests development will never finish. Can you define any specific goal for the regression tests you want to accomplish for 0.9?
I believe the goal from Alexandre was that he just wanted the frameworks stabilized, with documentation and some sample tests. (I know there is a framework in place, it was demonstrated at the conference, but I'm not sure if the API was frozen or not)
-James
On Tue, 19 Mar 2002, Andriy Palamarchuk wrote:
--- James Hatheway james@macadamian.com wrote:
For Wine 0.9
- Dll seperation (being able to build on windows
being a "Wish") - Dimi, Patrick, Steven, Alexandre, Scott
- Address Space Seperation - Alexandre
- Window Management - Ulrich, Mike, Alexandre
- Wine Server Protocols (DONE)
- Regression Testing - Francois, Andridy, Patrick,
Dimi, Andi, Steven
Hmm, Regression Tests development will never finish. Can you define any specific goal for the regression tests you want to accomplish for 0.9?
I think the goals is to have a complete Framework in place for 0.9.0 and to have enough tests to be reasonably confident that we won't need to change it.
- Documention -> Call for a FAQ maintainer Urivan, Andi, Jeremy Newman
- Bugzilla - Francois, Andridy, Jeremy Newman- to
create a wine-bug maillist ALL should commit to using bugbase
We should create a (meta?) bug for each task, and make bug "Wine 0.9" depend on these bugs.
Yes, actually it's the Wine 1.0 meta bug (#35) which is supposed to be renamed and updated. I have been volunteered for this and I will try to take care of it tonight.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!
-
Alexandre Julliard -
Andreas Mohr -
Andriy Palamarchuk -
Dimitrie O. Paun -
Eric Pouech -
Francois Gouget -
James Hatheway -
Jeremy White -
Michael Cardenas -
Steven Edwards -
Tony Lambregts -
Yven Leist