Re: Winebot
Dan Kegel wrote: Vit wrote: I'll write the manifest (a),(c) and post it onto Winebot Wiki. Cool... where is that? http://winebot.sandbox.cz/tracker/wiki/WinebotManifest Feel free to comment, propose enhancements. Regards Vit
Re: Winebot
Remco wrote: Will winebot be a win32 app or a linux app? Making it a win32 app and developing it on Windows would probably reveal more Wine bugs. Hi Remco, Winebot is a PERL/Linux code which calls BASH or AutoHotKey scripts. AutoHotkey is a Windows application, so I can safely say, that Winebot (using AutoHotkey) is both Linux and Windows application. Regards Vit
Re: Winebot
Will winebot be a win32 app or a linux app? Making it a win32 app and developing it on Windows would probably reveal more Wine bugs. Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
Re: Winebot
Wow You rpetty much leave us with nothing to complain about... if you truly stick to that, and help users, while still making sure you give the Devs word in their stead... It sounds like a sweet deal. On 3/23/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote: Hi all, first thanks for a lot of comments. I interpret this as a creative discussion helping to shape WINE project attitude to Winebot and Winebot project itself. I'll let Karl Lattimer to state his attitude with his Wine-Doors project. In the following words, I'm going to discuss my personal point of view, as I'm representing Winebot project. I'll first summarize some points extracted from the previous discussion: ------ 1. My goal in writing Winebot is to help Wine succeed 2. I pledge to use only the bare minimum of native DLLs in any Winebot recipe 3. 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 4. I will report bugs to the Wine project in the course of working on Winebot 5. 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. 6. I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts 7. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. 8. 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. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). -- Analyzing the objections written in discussion, I've found that you are missing the following: a) Clear statement, which will specify Winebot project's goals and attitude to its parent project - WINE. Sort of manifest. b) Results - working and actively supported regression testing scripts suite. c) Forwarding bugs and list of 'unclean' fixes to bugs.winehq.org. As I'm Debian and Ubuntu user I actively borrow knowledge from the Debian project. Each Winebot package shall have a maintainer responsible for package quality and for interfacing with WINE project(AppDb, Bugzilla, Testing, Fixing). Every official Winebot maintainer will be bound by sort of Winebot manifest stating the Winebot project's attitude to WINE project. I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation? ------ 1. My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing. 2., 3., 4. All Winebot packages should install only minimum neccessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to WINE bugzilla. 5. That's a relict from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages. 6. Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com 7. Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO. 8. User simply wants his application to work. Package maintainer, who prepa
re: Winebot
Vit wrote: I'll write the manifest (a),(c) and post it onto Winebot Wiki. Cool... where is that? I gladly accept any input to create a regression test repository, would you be so kind and point me to some list of programs / test miniprograms to make a reference implementation? I'd be glad to. I, Lei, and Nigel are just getting that going, and will be in touch via email. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Winebot
Hi all, first thanks for a lot of comments. I interpret this as a creative discussion helping to shape WINE project attitude to Winebot and Winebot project itself. I'll let Karl Lattimer to state his attitude with his Wine-Doors project. In the following words, I'm going to discuss my personal point of view, as I'm representing Winebot project. I'll first summarize some points extracted from the previous discussion: -- 1. My goal in writing Winebot is to help Wine succeed 2. I pledge to use only the bare minimum of native DLLs in any Winebot recipe 3. 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 4. I will report bugs to the Wine project in the course of working on Winebot 5. 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. 6. I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts 7. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. 8. 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. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). -- Analyzing the objections written in discussion, I've found that you are missing the following: a) Clear statement, which will specify Winebot project's goals and attitude to its parent project - WINE. Sort of manifest. b) Results - working and actively supported regression testing scripts suite. c) Forwarding bugs and list of 'unclean' fixes to bugs.winehq.org. As I'm Debian and Ubuntu user I actively borrow knowledge from the Debian project. Each Winebot package shall have a maintainer responsible for package quality and for interfacing with WINE project(AppDb, Bugzilla, Testing, Fixing). Every official Winebot maintainer will be bound by sort of Winebot manifest stating the Winebot project's attitude to WINE project. I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation? ------ 1. My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing. 2., 3., 4. All Winebot packages should install only minimum neccessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to WINE bugzilla. 5. That's a relict from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages. 6. Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com 7. Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO. 8. User simply wants his application to work. Package maintainer, who prepares the package, should interface with WINE developers whenever he spots a glitch. Package maintainer goes with new WINE versions and prepares a package for each WINE version. Package maintainer is therefore dedica
Re: Winebot / Wine-Doors Was: Road to 1.0
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
Winebot / Wine-Doors Was: Road to 1.0
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
Re: Winebot / Wine-Doors Was: Road to 1.0
On 3/22/07, Jan Zerebecki <[EMAIL PROTECTED]> 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
Winebot / Wine-Doors Was: Road to 1.0
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".
