Difference between revisions of "Winezeug"

From WineHQ Wiki
Jump to: navigation, search
(Add condensed BuildBot notes from old wiki)
(Add in notes for Appinstall and Yagmark)
 
Line 1: Line 1:
 +
__NOTOC__
 +
 
Over the years, Wine contributor Dan Kegel built up a veritable steamer-trunk of interesting scripts for testing, tweaking, and otherwise teaching Wine and WineHQ to do all kinds of tricks (even the early versions of [[Winetricks]]). For those interested in sorting through all his tools, keep on reading.
 
Over the years, Wine contributor Dan Kegel built up a veritable steamer-trunk of interesting scripts for testing, tweaking, and otherwise teaching Wine and WineHQ to do all kinds of tricks (even the early versions of [[Winetricks]]). For those interested in sorting through all his tools, keep on reading.
  
Line 24: Line 26:
  
 
When the repo was exported to Github from Google Code, the few wiki pages were loaded into a distinct ''wiki'' branch of the repo. However, only the ConvergedFrontends file was not entirely obsolete or superseded by the winetricks wiki, and it has now been merged into the [[Bottling Standards]] page on this wiki.
 
When the repo was exported to Github from Google Code, the few wiki pages were loaded into a distinct ''wiki'' branch of the repo. However, only the ConvergedFrontends file was not entirely obsolete or superseded by the winetricks wiki, and it has now been merged into the [[Bottling Standards]] page on this wiki.
 +
 +
== Appinstall ==
 +
Austin English developed a wrapper script called Appinstall that would configure the [http://www.autohotkey.com/ AutoHotkey] automation tool in a wine prefix, then use it to test installing various Windows programs. This is one of the ideas in Winezeug aimed at what a still active problem: how can we get more digestible test data from actual programs in the wild.
 +
 +
Because of that, there's a good chance Appinstall won't be unwound but rather revived in a new repo. In addition to the operational files being cleaned up, the docs will also get cleaned up, fleshed out, and merged with notes from the old wiki.
  
 
== BuildBot & Patchwatcher ==
 
== BuildBot & Patchwatcher ==
Line 33: Line 40:
  
 
Our current Wine TestBot gets the job done fine, but if we ever decide to transition to BuildBot, the groundwork done by Dan & Jeremy could give us a nice headstart.
 
Our current Wine TestBot gets the job done fine, but if we ever decide to transition to BuildBot, the groundwork done by Dan & Jeremy could give us a nice headstart.
 +
 +
== yagmark ==
 +
Another interesting idea directed more at diagnosing performance issues in wine (and feeding our ego by comparing them to Windows) was yagmark. Dan developed this set of scripts to automatically install and configure several graphics benchmarks in a prefix, then run them before processing the results.
 +
 +
This is still a cool idea for sure, and considering many wine users run graphics-intensive games, performance testing is still something where we could use more precision and systemization. However, there is little documentation (notes on the wiki will be merged into the tree) besides comments in the code itself. Also, the actual benchmarks used may be very outdated, though at first glance, tweaking the framework to use newer ones doesn't seem a difficult proposition.
  
 
[[Category:Data]] [[Category:Development]] [[Category:Quality Assurance]] [[Category:ToDo]]
 
[[Category:Data]] [[Category:Development]] [[Category:Quality Assurance]] [[Category:ToDo]]

Latest revision as of 11:59, 18 March 2016


Over the years, Wine contributor Dan Kegel built up a veritable steamer-trunk of interesting scripts for testing, tweaking, and otherwise teaching Wine and WineHQ to do all kinds of tricks (even the early versions of Winetricks). For those interested in sorting through all his tools, keep on reading.

Tango-style info icon.svg This page is not intended to be permanent. The goal is to keep hints and major notes here while doing some code archaeology on the Winezeug repo, a project that probably has at most a time-horizon of a few years (and much shorter if someone prioritizes it).

Getting Winezeug

Winezeug was originally hosted on Google Code, but when Google began unwinding their code hosting service, it was automatically exported to Github. As of this writing, winezeug was last updated a year and a half ago by Austin English and there's no sign that Dan's repo will be actively maintained.

Still if you're interested in downloading it as Dan left it on Google Code, you can clone it through git:

git clone https://github.com/dankegel/winezeug.git

Austin has also mentioned his fork, which is currently (March 2016) synced with Dan's:

git clone https://github.com/austin987/winezeug.git

Kyle Auble has also forked Dan's repo on his Bitbucket account and plans to dig through it from time to time, pushing any changes back to Bitbucket:

git clone https://bitbucket.org/kauble/winezeug-archaeology.git

Preliminary Observations

From a very cursory glance, the code in the repo seems to fall into several categories:

  • Random simple tests and cruft (the easy stuff to clear out)
  • Helper / Installer scripts, including early versions of winetricks and related tools
  • Some basic prototypes of an approach to prefix management
  • A couple of web-scrapers to mine the AppDB and report on popular titles (according to gamerankings.com)
  • Shims for using different testing tools on Wine
  • A collection of examples for trying out the Cmake build tool
  • Alternative versions of a possible testbot

When the repo was exported to Github from Google Code, the few wiki pages were loaded into a distinct wiki branch of the repo. However, only the ConvergedFrontends file was not entirely obsolete or superseded by the winetricks wiki, and it has now been merged into the Bottling Standards page on this wiki.

Appinstall

Austin English developed a wrapper script called Appinstall that would configure the AutoHotkey automation tool in a wine prefix, then use it to test installing various Windows programs. This is one of the ideas in Winezeug aimed at what a still active problem: how can we get more digestible test data from actual programs in the wild.

Because of that, there's a good chance Appinstall won't be unwound but rather revived in a new repo. In addition to the operational files being cleaned up, the docs will also get cleaned up, fleshed out, and merged with notes from the old wiki.

BuildBot & Patchwatcher

Dialog-warning.svg For now, this info makes sense here. Once these parts of winezeug have been thoroughly digested though, the paragraphs below (with updates) probably belong more on some part of the Wine TestBot page.

BuildBot is a mature, open-source continuous integration (build-and-test) service written in Python. It can be operated as a distributed installation, with a master server automatically pushing jobs out to slave servers. Dan Kegel and Jeremy White setup a BuildBot farm at WineHQ several years ago for feasiblity tests, before we settled on our current Wine_TestBot. It would monitor the wine-patches mailing list, automatically sending errors to Dan, who would personally filter out the false positives, then email the submitter and wine-devel about any legitimate errors.

Prior to the BuildBot test instance, Wine relied on Patchwatcher, a custom testbot whipped up by Dan to automatically check submitted patches against Wine Conformance Tests. After all these bespoke scripts became too much of a hassle to maintain though, the wine team decided to try other options, including existing projects like BuildBot or Jenkins.

Our current Wine TestBot gets the job done fine, but if we ever decide to transition to BuildBot, the groundwork done by Dan & Jeremy could give us a nice headstart.

yagmark

Another interesting idea directed more at diagnosing performance issues in wine (and feeding our ego by comparing them to Windows) was yagmark. Dan developed this set of scripts to automatically install and configure several graphics benchmarks in a prefix, then run them before processing the results.

This is still a cool idea for sure, and considering many wine users run graphics-intensive games, performance testing is still something where we could use more precision and systemization. However, there is little documentation (notes on the wiki will be merged into the tree) besides comments in the code itself. Also, the actual benchmarks used may be very outdated, though at first glance, tweaking the framework to use newer ones doesn't seem a difficult proposition.