Road to 1.0

[Vit Hrachovy]

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