Winebot

[Vit Hrachovy]

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