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 dedicated regular WINE tester and bug reporter. Package maintainer also filters user feedback to create a useful bug report, probably with a patch proposal in ideal situation.
Best regards Vit Hrachovy
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 vit.hrachovy@sandbox.cz 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:
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
- 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.
- I will help Wine by writing not just Winebot recipes, but also basic
application regression test scripts
- If developers working on projects such as Wine-Doors contributed to
Wine, then the bugs would be fixed even faster.
- 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?
- 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.
- 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.
- 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
- 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.
- 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 dedicated regular WINE tester and bug reporter. Package maintainer also filters user feedback to create a useful bug report, probably with a patch proposal in ideal situation.
Best regards Vit Hrachovy
-
Bryan Haskins -
Vit Hrachovy