Jeremy White put out for comment an RFC covering the Wine documentation aspects. This follows the first steps already made (see previous issue). Jeremy wrote: As part of the Wine 1.0 effort, we've been working on improving the Wine documentation.

We have a proposal for a way to overhaul the documentation system, and we'd like some feedback.

We start with the following goals:

1. Documentation should be easy to find
2. Documentation should be clear (the user should quickly see the thing that he or she wants, and there should be no confusion as to which document is 'right')
3. Documentation should be consistent (the documentation should look the same whether it is on winehq or on a mirror, or in a tarball).
4. Documentation should be easy to change.

We propose the following visible changes:

1. Entry documentation page should be simplified and prioritized
2. Many multiple disconnected (but similar and/or redundant) documents should be merged under a consistent format.
3. Centralize all of the documentation under one CVS point, possibly as a new CVS tree, possibly just as the documentation/ branch of the Wine CVS tree.
4. Switch the FAQ to use a FAQ-O-MATIC, to facilitate updates and changes to it, and to allow the creation of a world editable late breaking bugs section.

Jeremy then provided a link to such an experimental page

Then, Jeremy proposed some changes in the way documentation is handled; basically, he was keen on having a separate CVS tree dedicated to documentation. Alexandre Julliard strongly preferred to keep the source and documentation trees together, so that changes to the code are reflected to the documentation.

Dimitrie O. Paun even suggested to move documentation related to a given DLL into a specific subdirectory of the DLL source. Dimi felt this had several advantages:

• greater probability of having the docs maintained
• easier for people to get into the project
• possibility to maintain the dll separately

No final agreement seems to have been reached.

James Hatheway ran into some networking issues: The app that I am debugging from time to time sends broadcast (255.255.255.255) UDP packets using the winsock function sendto(). On Windows, if the default gateway is not configured, the sendto() function still sends the UDP packet onto the local network. In Linux, if no default gateway is set, sendto() fails with a "network unreachable". Since it is possible to have an isolated local network that isn't connected to the internet, I guess it is possible to not have a gateway configured, so I want to fix WSOCK32_sendto() to be like Windows and handle this.

Alexandre Julliard didn't like the proposed fix, and rather suggested to report an explicit error to the user, asking him/her I do need to be politically correct to add an explicit route from 255.255.255.255 to the local network.

Martin Pilka announced: wine-configuration wizard 0.3beta is now available at http://wine.codeweavers.com/winecfg.shtml

It's still an early beta version, so all your comments are welcomed. This is the first implementation of the tool defined earlier on (read previous issue for the details).

Douglas Ridgway announced: Codeweavers has been kind enough to set up a new bug tracking system for Wine using Bugzilla. This will replace the old system. You can see a preview at http://wine.codeweavers.com/bugzilla, which is supposed to be fully live and the official bug database by the end of this week.

The old system is currently only accessible at http://ursula.gmcl.com/Bugs/, and has 500+ existing reports. I can't guarantee that this system will remain accessible beyond the end of the week. It might be worthwhile trying to make sure that important reports are copied into the new system before they are lost / made inaccessible.

A big thank you to Codeweavers for setting up and maintaining this new system. Good bug tracking is a crucial part of making Wine great, and this system promises to be a significant improvement over what it's replacing.

Even if it's not fully operational yet, you can still have a look at it.