My two cents about winetools and the suggestions I read in Issue 308

[Philip V. Neves]

What I'm seeing here with the whole debate with wine and winetools is 
that its a  configuration management issue. The project is getting into 
the stage where testing needs to be accomodated and so does getting 
things working. I think whats currently available for managing 
configurations to wine is innadequate.  Even winecfg provides an 
interface that is innadequate for making many changes in terms of dll 
overrides.  Plus it doesn't provide a mechanism for rolling those 
changes back. Or even managing multiple configurations or modes so that 
problems can be issolated. I think whats is comming out of the 
winetools  debate is better tools are needed for configuration 
management.  This isn't very revolutionary. Its a natural part of the 
software development life cycle. As a project  starts emerging from the 
development phase ways to provide better configuration management start 
showing themselves.

Something that interfaces with the AppDB would be good. It would make 
things easier. I think, given the complaints given by the developers are 
also valid but so are the complaints made by the people trying to use 
the program and even the testers.  Most other projects don't need such 
tools but this one does given what its trying to accomplish and the 
complexity of whats being accomplished.  Besides even windows XP has a 
roll back feature now to fix problems. Why doesn't wine considering its 
attempting a bug for bug compatibility with windows. This would be a 
wise thing to implement just for sanities sake.

So I'd like to provide an addition to Jason Greens brain dump

    * AppDB would have to be extended to be able to get and report this
      data, and it would make sense for each App's maintainer to be able
      to manage that information.
    * Biggest issue here is that this information could have a tendency
      to change very rapidly, so it might overload the app maintainers
      if they had to track this for each version of wine. What I think
      would make sense is to have regular snapshots (every 3 months?)
      and release a new version of "Winetools Plus" or whatever you want
      to call this thing a month later to give the maintainers time to
      update each of their apps based on the frozen version. (I think
      multiple versions of the AppDB would be useful. Similar to the
      Release and Release candidate type way of doing things.)
    * Data needed: AppID, AppVersionID, WineVersionID, Window Version,
      DLL Overrides, Window settings (fullscreen/windowed - sometimes
      and issue), Sound options, Video acceleration required, General
      notes or HOWTO's, etc. You would need separate overrides/settings
      for Installing vs. Running the app.
    * AppDB could dump this information to an xml format which
      "Winetools Plus" could be distributed with. Maybe have an option
      to download the latest xml file directly from winehq.org.
    * The 'Winetools Plus' front-end would just be a menu which would
      query all of the apps in the xml dump. The user picks they app
      they want to install, and it reads the necessary information,
      verifies the source installation media, and goes at it.
    * Applying patches to apps might get tricky (e.g., where wine only
      successfully runs version 1.5 of the app, but 1.0 is on the CD),
      but I'm sure it could be worked out.
    * A Way to roll back DLL overrides.
    * A Way store roll  multiple registry configurations so  that we
      establish a base reference configuration and a test configuration.
      Or even multiple test configurations.
    * An AppDB tool that allows changes to the DLL configuration in the
      AppDB to be made easily.
    * A way to detect the version of wine and provide configuration
      changes given that version of wine.
    * A way to report bugs to the appDB maintainers about configuration
      problems.

A nice to have would be

      Something that allows the AppDB maintainers to distribute tweeks 
to the configuration changes in the AppDB to users.  So that even if we 
aren't installing the programs on the system. The tweeks can still be 
made on the fly.  This would eliminate having to blow away the .wine 
directory all the time.  Blowing away the .wine directory is not a 
desirable.  A way for wine developers to distribute a test configuration 
would also be a useful thing. That way we can test the software with 
what the developers want us to test rather then shooting in the dark 
only to see that the bug we reported is the same as some other bug we 
reported.

Such tools would be useful in debugging the entire framework and speed 
up development. These are suggestions. I hope they help a bit.