Rob wrote:
I think the only viable way to drive for 1.0 is feature or applications targets, with applications compatibility driving test cases and bug fixing.
Yes indeedy. And the only reason I haven't jumped up and posted a proposed list of applications to support for 1.0 is that real app testing is gobs of work, more than we have resources for. The tests at http://cxtest.org could be an important part of the equation. FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. No promises, though. - Dan
Dan Kegel wrote:
Rob wrote:
I think the only viable way to drive for 1.0 is feature or applications targets, with applications compatibility driving test cases and bug fixing.
Yes indeedy. And the only reason I haven't jumped up and posted a proposed list of applications to support for 1.0 is that real app testing is gobs of work, more than we have resources for.
The tests at http://cxtest.org could be an important part of the equation.
FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. No promises, though. - Dan
AutoHotkey (http://www.autohotkey.com) seems to do very well. I'm using it for automated installation of lots of Windows programs into WINE bottles as an initialization (something similar to winetricks). It's very well documented, too. Writing a series of batch scripts for automated testing is very easy. In fact complete Wine-Doors / Winebot projects can serve for this purpose too - as a repository of automated WINE tests. Regards Vit
Vit wrote:
Dan Kegel wrote:
FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier.
AutoHotkey (http://www.autohotkey.com) seems to do very well. I'm using it for automated installation of lots of Windows programs into WINE bottles as an initialization
Yes, that's what we're using. We drive it with a 'small' python script that verifyies a list of registry keys and files were installed, downloads the app to install, etc.
(something similar to winetricks).
Nah, winetricks is by design never going to use anything like autohotkey, it's much smaller and crappier than that. It's meant to be a little tool that does one thing (install redistributable runtime libraries) and does it with a minimum of code and glitz.
Writing a series of batch scripts for automated testing is very easy.
In fact complete Wine-Doors / Winebot projects can serve for this purpose too - as a repository of automated WINE tests.
Yes, when I heard that Wine-Doors used autohotkey, I realized the same thing. (I gather winebot is part of wine-doors, http://www.wine-doors.org/trac/browser/sandbox/contrib/prototype/winebot.pl) I am quite skeptical of wine-doors, though, for various reasons. (For instance, the web site is both overdesigned and amateurish, the project was founded with way too much self-promotion, and the goals were both grandiose and poorly explained. Doesn't mean they'll fail, but it does mean I find it painful to interact with them.) - Dan
Dan Kegel wrote:
In fact complete Wine-Doors / Winebot projects can serve for this purpose too - as a repository of automated WINE tests.
Yes, when I heard that Wine-Doors used autohotkey, I realized the same thing. (I gather winebot is part of wine-doors, http://www.wine-doors.org/trac/browser/sandbox/contrib/prototype/winebot.pl)
I am quite skeptical of wine-doors, though, for various reasons. (For instance, the web site is both overdesigned and amateurish, the project was founded with way too much self-promotion, and the goals were both grandiose and poorly explained. Doesn't mean they'll fail, but it does mean I find it painful to interact with them.) - Dan
WineBot (http://winebot.sandbox.cz) is a sort of lightweight implementation of some core thoughts, but with command line based interface and less dependencies. Both projects share some core ideas and data file formats. WineBot goals are much smaller in scope than Wine-Doors ones, going in smaller steps. The main goal is to replace obsolete and almost unmaintainable winetools project. Main idea is to make repositories of supported application packages, both installed from CD, HDD or downloaded from net. For example to install Oblivion by placing CD into tray and entering winebot install tes_oblivion-1.1.511uk Or in case of Wine-Doors - insert CD, run wine-doors, select Games repository, click to add Oblivion to install queue. Given list of manual steps required to install Oblivion http://www.uesp.net/wiki/Oblivion:Linux this can be automated easily and comfort would be similar to using Loki installers. Regards Vit
Vit wrote:
WineBot (http://winebot.sandbox.cz) is a sort of lightweight implementation of some core thoughts, but with command line based interface and less dependencies. Both projects share some core ideas and data file formats. WineBot goals are much smaller in scope than Wine-Doors ones, going in smaller steps. The main goal is to replace obsolete and almost unmaintainable winetools project.
You've got my attention. That sounds like it fixes almost all the problems I have with Wine-doors.
Given list of manual steps required to install Oblivion http://www.uesp.net/wiki/Oblivion:Linux this can be automated easily ...
The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. We would prefer to fix the bugs. For instance, the steps related to sound and winecfg should just go away, hopefully this summer. Likewise with directx and registry settings. That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'. - Dan
On 3/20/07, Dan Kegel <dank(a)kegel.com> wrote:
The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine.
...
That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'.
Pay students $4500 to interest themselves in the Wine codebase over the summer and to make some well defined and useful contribution... ... ... until all the bugs are fixed? <ducks> Just a thought. :) --tim
On Wednesday 21 March 2007 00:08, Tim Schmidt wrote:
On 3/20/07, Dan Kegel <dank(a)kegel.com> wrote:
The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine.
...
That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'.
Pay students $4500 to interest themselves in the Wine codebase over the summer and to make some well defined and useful contribution...
http://code.google.com/soc/wine/about.html Like that? Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.
On 3/20/07, Kai Blin <kai.blin(a)gmail.com> wrote:
http://code.google.com/soc/wine/about.html
Like that?
Yeah. That was me attempting something resembling humor. GSoC is exactly what I meant. --tim
On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote:
Given list of manual steps required to install Oblivion http://www.uesp.net/wiki/Oblivion:Linux this can be automated easily ...
The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. We would prefer to fix the bugs. For instance, the steps related to sound and winecfg should just go away, hopefully this summer. Likewise with directx and registry settings.
That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'. - Dan
Hi Dan, I understand the WINE developers' attitude for such temporary fixups as listed above in Oblivion in Linux Wiki. However, usage scenarios for automated SW installer applications offer far more. First, it somehow mirrors info from AppDB. It can display application usability for range of WINE versions and also make available application on older WINE versions. For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now. Second, using automated tools, regression tests can be fully automated, so building a repository of free game demos or applications is just a matter of time. Packages can be suited to fit specific WINE versions or made generic. Install scripts can fully automate / simulate 'normal' Windows installation process. Creating regression testing DB is going hand in hand with package installer creation, so costs are low to nothing. Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this. Third, having list of 'hacks' stored in 'unified' manner within repository simplifies access to 'fixups' for outstanding issues. At least they will be at one place (similar to AppDB now). ----- I've been thinking heavily before I've started participating on Wine-Doors and coding on Winebot. I've made conclusion that I cannot hurt WINE, given the potential of these automation tools. However, in future it may cause trouble for commercial WINE implementations, that are selling nice GUI and 'easy installation'. Regards Vit
On Thursday 22 March 2007 16:25, Vit Hrachovy wrote:
First, it somehow mirrors info from AppDB. It can display application usability for range of WINE versions and also make available application on older WINE versions.
For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now.
I'm not sure if that's a valid point. Breaking your system by installing proprietary dlls and system hacks or breaking your system by installing a more current wine version doesn't look too different to me. (Especially I'd like to question this logic for software that still calls itself beta. ;) )
Second, using automated tools, regression tests can be fully automated, so building a repository of free game demos or applications is just a matter of time. Packages can be suited to fit specific WINE versions or made generic. Install scripts can fully automate / simulate 'normal' Windows installation process.
I'm not entirely sure how making sure the package installs qualifies as a full regression test.
Creating regression testing DB is going hand in hand with package installer creation, so costs are low to nothing.
In fact, they have to be well-maintained or they are worthless. Alessandro Pignotti is working on dplayx.dll currently. However, it's not 100% useful yet, so the current tests would all use native dplayx.dll. Once Alessandro fixes dplayx.dll, someone needs to disable the override, or Alessandro's code is never tested. Looking at appdb, only the most popular apps have some sort of frequent testing.
Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this.
If the problem of e.g. dll overrides is correctly handled, maybe. If the same man hours went into writing regression tests, the same would apply, I guess. :) Of course it would take nothing but a working, maintained regression test suite to prove me wrong. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.
On 3/22/07, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote:
On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote:
Given list of manual steps required to install Oblivion http://www.uesp.net/wiki/Oblivion:Linux this can be automated easily ...
The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. We would prefer to fix the bugs. For instance, the steps related to sound and winecfg should just go away, hopefully this summer. Likewise with directx and registry settings.
That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'. - Dan
Hi Dan, I understand the WINE developers' attitude for such temporary fixups as listed above in Oblivion in Linux Wiki.
However, usage scenarios for automated SW installer applications offer far more.
First, it somehow mirrors info from AppDB. It can display application usability for range of WINE versions and also make available application on older WINE versions.
For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now.
Second, using automated tools, regression tests can be fully automated, so building a repository of free game demos or applications is just a matter of time. Packages can be suited to fit specific WINE versions or made generic. Install scripts can fully automate / simulate 'normal' Windows installation process.
Creating regression testing DB is going hand in hand with package installer creation, so costs are low to nothing.
Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this.
Third, having list of 'hacks' stored in 'unified' manner within repository simplifies access to 'fixups' for outstanding issues. At least they will be at one place (similar to AppDB now).
-----
I've been thinking heavily before I've started participating on Wine-Doors and coding on Winebot. I've made conclusion that I cannot hurt WINE, given the potential of these automation tools.
If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, and we need as much testing and bug reporting as possible. You take away users that help the development process, and attach them to your project so that when they have a problem with app xyz, they file a report with your project, not Wine, and you add the necessary hack to make it work for them. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). If you have any reason to believe that you are helping Wine, I'd sure love to hear it. -- James Hawkins
If you are making it extremely easy for users to run with native dlls
and hacky workarounds, then you are hurting Wine. Wine is still beta, That's true... and people technically should only be using wine for the pure sake of testing and helping fix usage. LEt's be honest, very few use it for that, they just want it to work, they use wine for the use the Devs want out of 1.0. Saying to someone that because it doesn't work by default, we're not going to let you use it, or in general make it hard for them defeats the goal of the *actual program*, Joe XYZ wants to play Oblivion, He Finds it doesn't work! He looks around and sees that if he does a lot of various things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of ever submitting bugs at all, is this bad? Hell yes it is. We should educate at how important it is for a program like Wine to have nice detailed Bug Tracking, but at the same time, can you blame him for just wanting it to work, easily? As long as the user, at some point, realized, hey this doesn't work out of the box, the job is done to some degree. To summarize, If a user never was going to report things, that's bad, he should be educated, but at the same time, if he still wouldn't, shouldn't it be our job as the community to make it easy for him? This goes back to the WineTools thing... that was bad though, even though at face it seems the same... in reality people were starting to just say Install Wine, then you *need* to install winetools and run the base install thing, without ever actually saying "HEY! Newbs! This wont work so you should install zyx to make it work as a temporary solution until such a time as it's fixed in the wine tree." OR something similar. I guess my point is two fold: -The user needs to know about bug reporting. -The user needs to know what it means for something to not work 'out-of-the-box', and what exactly a 'dirty little hack' or the like is. end rant and we need as much testing and bug reporting as possible. You take
away users that help the development process, and attach them to your project so that when they have a problem with app xyz, they file a report with your project, not Wine, and you add the necessary hack to make it work for them. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). If you have any reason to believe that you are helping Wine, I'd sure love to hear it.
-- James Hawkins
-- Cheers, Bryan
On 3/22/07, Bryan Haskins <kingofallhearts999(a)gmail.com> wrote:
If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta,
That's true... and people technically should only be using wine for the pure sake of testing and helping fix usage. LEt's be honest, very few use it for that, they just want it to work, they use wine for the use the Devs want out of 1.0. Saying to someone that because it doesn't work by default, we're not going to let you use it, or in general make it hard for them defeats the goal of the *actual program*,
No one here says they can't use Wine if their app doesn't work, and we're certainly not trying to make it harder for them if that is the case. The argument is irrelevant though, as it doesn't follow the original question, "Does my development of Wine-Doors hurt Wine."
Joe XYZ wants to play Oblivion, He Finds it doesn't work! He looks around and sees that if he does a lot of various things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of ever submitting bugs at all, is this bad? Hell yes it is. We should educate at how important it is for a program like Wine to have nice detailed Bug Tracking, but at the same time, can you blame him for just wanting it to work, easily? As long as the user, at some point, realized, hey this doesn't work out of the box, the job is done to some degree.
The optimal outcome of this scenario is that Joe XYZ reports his problems running Oblivion to the Wine development community using bugzilla. The Wine development community then fixes these bugs, leaving Joe XYZ very satisfied with Wine. The next possible outcome is that it takes a little while for the bugs to be fixed, though they'll be fixed at some point, but we do try our hardest. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster.
To summarize, If a user never was going to report things, that's bad, he should be educated, but at the same time, if he still wouldn't, shouldn't it be our job as the community to make it easy for him?
Make it easy for him to report the bugs? Yea we should make it as easy as possible.
This goes back to the WineTools thing... that was bad though, even though at face it seems the same... in reality people were starting to just say Install Wine, then you *need* to install winetools and run the base install thing, without ever actually saying "HEY! Newbs! This wont work so you should install zyx to make it work as a temporary solution until such a time as it's fixed in the wine tree." OR something similar.
Wine-Doors is the exact same thing as WineTools from the perspective of the Wine developers.
I guess my point is two fold: -The user needs to know about bug reporting.
Definitely, and we're doing a good job at it so far.
-The user needs to know what it means for something to not work 'out-of-the-box', and what exactly a 'dirty little hack' or the like is.
Users know when things don't work out-of-the-box, whether they know what the term means or not, and we wouldn't have to worry about a user knowing what a 'dirty little hack' is if projects like Wine-Doors didn't exist. -- James Hawkins
On Thu, Mar 22, 2007 at 10:03:46PM -0600, James Hawkins wrote:
If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster.
I think that this is not necessarily (always) true, probably not even most of the time. Does a developer of e.g. Wine-Doors even has the skill to fix these bugs? It's at least not the same skill set. (I think one can say that some good amount of Wine bugs are harder to fix than coding something like Wine-Doors.) See another mail by me in this thread, sent somewhat earlier, for some provisions that if followed would make something like Wine-Doors IMHO useful to wine (not only for users but also for developers). However if those provisions are not met, it would probably only result in another winetools and I don't want that either. Do you think that with those provisions it would still not help wine? I think it's somewhat similar to: "If all the work on coding those debuggers is spend on writing proper code, we would get bug free much sooner." It's the "work on tools for project" vs "work on project" trade-off. Jan
I have a request of these third party tool developers.... Please add a link on your front page to the WineHQ PayPal account for Donations! Thank You! Tom Wickline
Yea, I agree with what you said, I didn't mean for my message to sound like people were doing anything blatantly wrong, the fact is though, if we like them or hate them from a development standpoint, people love these work arounds as users, and, it's just the evolution of the community that will make things like this. For the user it's make it make it work quick, more so than get fixes into the tree. Since we can't just stop the projects, which I don't think we would *really* want to, working aorund them is the best bet. Maybe talk with the maintainers of these so called Wine GUIs, and have them implement methods of sending in reports. Not to mention that we could have some kind of an unexpected kill catch to compile bugreports automatically, and tell the user how to go about submitting it, or even do it for them, to some degree we could have information on individual fix mes sent as well, you could imagine seeing which 'fixme' was spit out the most, then focusing on it. Things like that would not only help users get to the devs, but help the devs stay on track of whats best needed, for those that focus on the general need, rather than the "this doesn't work for me, I'll fix it" way, which isn't so bad in itself. I don't know... I'm an idealist =] On 3/23/07, James Hawkins <truiken(a)gmail.com> wrote:
On 3/22/07, Bryan Haskins <kingofallhearts999(a)gmail.com> wrote:
If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta,
That's true... and people technically should only be using wine for the
pure
sake of testing and helping fix usage. LEt's be honest, very few use it for that, they just want it to work, they use wine for the use the Devs want out of 1.0. Saying to someone that because it doesn't work by default, we're not going to let you use it, or in general make it hard for them defeats the goal of the *actual program*,
No one here says they can't use Wine if their app doesn't work, and we're certainly not trying to make it harder for them if that is the case. The argument is irrelevant though, as it doesn't follow the original question, "Does my development of Wine-Doors hurt Wine."
Joe XYZ wants to play Oblivion, He Finds it doesn't work! He looks around and sees that if he does a lot of various things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of ever submitting bugs at all, is this bad? Hell yes it is. We should educate at how important it is for a program like Wine to have nice detailed Bug Tracking, but at the same time, can you blame him for just wanting it to work, easily? As long as the user, at some point, realized, hey this doesn't work out of the box, the job is done to some degree.
The optimal outcome of this scenario is that Joe XYZ reports his problems running Oblivion to the Wine development community using bugzilla. The Wine development community then fixes these bugs, leaving Joe XYZ very satisfied with Wine. The next possible outcome is that it takes a little while for the bugs to be fixed, though they'll be fixed at some point, but we do try our hardest. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster.
To summarize, If a user never was going to report things, that's bad, he should be educated, but at the same time, if he still wouldn't, shouldn't it be our job as the community to make it easy for him?
Make it easy for him to report the bugs? Yea we should make it as easy as possible.
This goes back to the WineTools thing... that was bad though, even though at face it seems the same... in reality people were starting to just say Install Wine, then you *need* to install winetools and run the base install thing, without ever actually saying "HEY! Newbs! This wont work so you should install zyx to make it work as a temporary solution until such a time as it's fixed in the wine tree." OR something similar.
Wine-Doors is the exact same thing as WineTools from the perspective of the Wine developers.
I guess my point is two fold: -The user needs to know about bug reporting.
Definitely, and we're doing a good job at it so far.
-The user needs to know what it means for something to not work 'out-of-the-box', and what exactly a 'dirty little hack' or the like is.
Users know when things don't work out-of-the-box, whether they know what the term means or not, and we wouldn't have to worry about a user knowing what a 'dirty little hack' is if projects like Wine-Doors didn't exist.
-- James Hawkins
-- Cheers, Bryan
On 3/22/07, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote:
For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now.
I suspect they will be willing to update Drake to wine-1.0 when we release it, since it will be far, far superior to wine-0.9.9.
Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this.
That's certainly true, but only for installers. We can probably handle scripting the installers ourselves. The real work will be in scripting tests of the full apps, which you're not contemplating doing.
Third, having list of 'hacks' stored in 'unified' manner within repository simplifies access to 'fixups' for outstanding issues. At least they will be at one place (similar to AppDB now).
Pragmatically, I understand where you're coming from. What's missing is for you to declare things like: * My goal in writing Winebot is to help Wine succeed * I pledge to use only the bare minimum of native DLLs in any Winebot recipe * I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app * I will report bugs to the Wine project in the course of working on Winebot * I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts That last one especially would endear you to the Wine community. Cheers, Dan
I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the provisions detailed here are also compatible with his views of Wine-Doors. Something like Winebot could possibly save me much time while testing and developing. I reinstalled certain applications or workarounds countless times, automating it thus would make working on Wine less tedious. So I really want something like Winebot to be compatible with developing on Wine and to be something we could safely recommend to users and developers. It could make it easier to check if a bug is valid: Imagine there may be a command like: WINEPREFIX=~/apps/wine-foo winebot install --clean foo The argument --clean makes sure that the wineprefix does not exist before the install starts (refuses to proceed otherwise). It then would print to stdout that the wineprefix does not exist, the wine version, the winedoors version and the URL and possible other identification of the Winebot recipe (and probably other things during the install). So if the user saves the output and attaches it one can instantly rule out many possible errors on the part of the user. On Thu, Mar 22, 2007 at 10:42:20AM -0700, Dan Kegel wrote:
* My goal in writing Winebot is to help Wine succeed * I pledge to use only the bare minimum of native DLLs in any Winebot recipe * I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app * I will report bugs to the Wine project in the course of working on Winebot
Having a bugreport for every hack that is used is very important. In my view these points would certainly fix most of the possible problems with something like Winebot.
* I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts
This would be really nice and would give you much credibility with Wine developers, but it is IMHO not a must. I mean we don't say all patches must be accompanied by tests either. There are two other possible problems with something like Winebot: Hacks for one application can interfere with hacks for another application. Setting dll overrides or other hacks only per application might be a good idea, but is error prone (missing some part that need the hack and not properly restricting the hack). The best solution is to have one WINEPREFIX for each application. This can simply be done by needing the environment variable WINEPREFIX set (not defaulting to ~/.wine ) and warning if it is set to ~/.wine . http://winebot.sandbox.cz/tracker says under "Typical usage scenario": * User runs winebot first time. Winebot asks user for his name, his company name and proceeds to download and install the basic Windows compatibility programs into ~/.wine (or other WINE bottle directory) * After bottle initialization (installation of basic compatibility programs) user is then capable of using winebot to install the packages from winebot repository Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need. Do you think these provisions are compatible with your idea of Winebot (same question for Karl Lattimer and Wine-Doors)? Jan PS: The link to wine-doors.org on the top of http://winebot.sandbox.cz/tracker is missing the "s".
On 3/22/07, Jan Zerebecki <jan.wine(a)zerebecki.de> wrote:
I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the provisions detailed here are also compatible with his views of Wine-Doors.
Something like Winebot could possibly save me much time while testing and developing. I reinstalled certain applications or workarounds countless times, automating it thus would make working on Wine less tedious. So I really want something like Winebot to be compatible with developing on Wine and to be something we could safely recommend to users and developers.
It could make it easier to check if a bug is valid: Imagine there may be a command like:
WINEPREFIX=~/apps/wine-foo winebot install --clean foo
The argument --clean makes sure that the wineprefix does not exist before the install starts (refuses to proceed otherwise). It then would print to stdout that the wineprefix does not exist, the wine version, the winedoors version and the URL and possible other identification of the Winebot recipe (and probably other things during the install). So if the user saves the output and attaches it one can instantly rule out many possible errors on the part of the user.
On Thu, Mar 22, 2007 at 10:42:20AM -0700, Dan Kegel wrote:
* My goal in writing Winebot is to help Wine succeed * I pledge to use only the bare minimum of native DLLs in any Winebot recipe * I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app * I will report bugs to the Wine project in the course of working on Winebot
Having a bugreport for every hack that is used is very important. In my view these points would certainly fix most of the possible problems with something like Winebot.
* I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts
This would be really nice and would give you much credibility with Wine developers, but it is IMHO not a must. I mean we don't say all patches must be accompanied by tests either.
There are two other possible problems with something like Winebot:
Hacks for one application can interfere with hacks for another application. Setting dll overrides or other hacks only per application might be a good idea, but is error prone (missing some part that need the hack and not properly restricting the hack). The best solution is to have one WINEPREFIX for each application. This can simply be done by needing the environment variable WINEPREFIX set (not defaulting to ~/.wine ) and warning if it is set to ~/.wine .
http://winebot.sandbox.cz/tracker says under "Typical usage scenario": * User runs winebot first time. Winebot asks user for his name, his company name and proceeds to download and install the basic Windows compatibility programs into ~/.wine (or other WINE bottle directory) * After bottle initialization (installation of basic compatibility programs) user is then capable of using winebot to install the packages from winebot repository
Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need.
Do you think these provisions are compatible with your idea of Winebot (same question for Karl Lattimer and Wine-Doors)?
Please keep Winebot (or any non-Wine project) development discussion on the appropriate Winebot mailing list. -- James Hawkins
Hello all, Just thought I would through in my $.02 I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born. At the last Conf if memory serves me correctly there was mention of a feature freeze happening sometime early this year. And I would only guess to say the release notes after the freeze would read "X" amount of bugs were fixed in this release, as no new features would be implemented. So the question is not when will 1.0 be released but when will the freeze go into effect?
On Thu, 2007-03-22 at 23:38 -0400, Tom Wickline wrote:
Hello all,
Just thought I would through in my $.02
I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born.
At the last Conf if memory serves me correctly there was mention of a feature freeze happening sometime early this year. And I would only guess to say the release notes after the freeze would read "X" amount of bugs were fixed in this release, as no new features would be implemented.
So the question is not when will 1.0 be released but when will the freeze go into effect?
If we do this right, we could time the release of Wine 1.0 to barely precede the next wave of Linux distributions (eg, Ubuntu Feisty + 1), putting them in a very good position to face Vista. Thanks, Scott Ritchie
"Tom Wickline" <twickline(a)gmail.com> writes:
I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born.
At the last Conf if memory serves me correctly there was mention of a feature freeze happening sometime early this year. And I would only guess to say the release notes after the freeze would read "X" amount of bugs were fixed in this release, as no new features would be implemented.
That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too... -- Alexandre Julliard julliard(a)winehq.org
On Friday 23 March 2007 20:26, Alexandre Julliard wrote:
"Tom Wickline" <twickline(a)gmail.com> writes:
I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born.
That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too...
Just please don't freeze during Summer of Code. I had that while trying to get my 2005 work in, and that's really depressing. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.
On Thu, 2007-03-22 at 16:25 +0100, Vit Hrachovy wrote:
However, usage scenarios for automated SW installer applications offer far more.
First, it somehow mirrors info from AppDB. It can display application usability for range of WINE versions and also make available application on older WINE versions.
For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now.
I'm going to be providing packages for new Wine releases in Dapper (and later Ubuntu long term support versions) for the next few years, so there's no real need for targeted installations at this point. Maybe, once Wine is a little more mature we can put a stabilized "1.0-like" release into distributions and then target that. At this point, however, it's not a real important goal compared with just fixing Wine, as most users keep current with Wine (such as from the Apt repository). Thanks, Scott Ritchie
participants (10)
-
Alexandre Julliard -
Bryan Haskins -
Dan Kegel -
James Hawkins -
Jan Zerebecki -
Kai Blin -
Scott Ritchie -
Tim Schmidt -
Tom Wickline -
Vit Hrachovy