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
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






--
Cheers,
Bryan


Reply via email to