World Wine News : les nouvelles de Wine

WinNT4 is passing now for the first time since a long time(maybe since ever?). So special congratulations to Paul Vriens, who spent much time making the test-suite run on NT4. This is a great step for the test-suite. Now NT4, 2K, XP and 2K3 are passing partially. Keep it up!

• Updated version of Gecko
• Significant Wine64 improvements
• Many new codecs, protocols and formats supported
• Provide XShm and bitmap stretching performance.
• Improved Memory Management
• FBO becoming the default for D3D

So, briefly:

Over the past few months, users have added an average of between 12 and 14 bugs every day.

Since June 1st: - 412 total bugs filed - 87 bugs resolved invalid - 227 bugs resolved fixed - 133 bugs confirmed but not resolved (status new) - 292 bugs created but unconfirmed

Doing some subtraction that means we have 292 new untriaged bugs, but we triaged or fixed (412-292-87-227-133) = 327 old bugs.

So, we're swimming above water, which is good. But at this rate it'll be years before we triage every bug. So, let's do something :)

Bug Jam this Monday!

One idea that has been tried in the past is to hold regular bug days. We've had a lot of success with them in Ubuntu as a way of organizing non developer volunteers, especially when we focus the event on a particular package. Today's bug day, for instance, tackled over a 100 Synaptic bugs: https://wiki.ubuntu.com/UbuntuBugDay/20090716

I'd like to attempt this in Wine. We tried it once in the past, but no one's organizing it now. Even if it's just me and 2 people testing a handful of bugs in our favorite apps, it'll still sink a good number of bugs and help drain the swamp.

I'm picking Monday for bug day for a few reasons - it's both after a new release and after the weekend, so users will have already had time to play their games and see if they're still affected. If there's any sort of success, hopefully this will become a regular event.

So, if you're into bug triage, please come and join me in #winehackers this Monday. The purpose of triaging bugs is to ultimately get them fixed, so if you're a developer and would rather work on patches then by all means do that instead.

I've created a wiki page for the event here: http://wiki.winehq.org/BugDay When we're done I'll poke BugZilla for some stats and we can see how much of a success the event was.

Thanks,
Scott Ritchie

Hello everyone,

I've just returned from the Ubuntu Developer Summit in Barcelona last week. A lot of interesting stuff that concerns Wine happened there, and a lot of applies to every distro. I'll give a brief summary in this email.

Audio:

First, I talked with a Pulseaudio expert about what we can do to make things work better. He said that if we want good compatibility we will need our ALSA stack to use the Pulseaudio safe subset: http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a metabug tracking this here: http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset can cause most problems with stuttering or even complete drop off.

I'm not completely familiar with how sound works in Wine, but in the past I remember that one complaint about PulseAudio over ALSA was latency. Latency issues these days are mostly due to bad kernel configurations, which Lennart wrote about here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150.html.

In the meantime we should develop for the future using kernels with preempt enabled at 1000 HZ. Currently neither Open SuSE nor Ubuntu are configured this way, however I know in the case of Ubuntu that this is being fixed for next release. In particular, if you develop on Ubuntu, you should either upgrade to Karmic Alphas or install a custom kernel. The -rt flavor of the kernel is known to have problems as well.

Printing:

A printing expert from http://openprinting.org says we should output .pdf files to cups rather than postscript. .pdf are becoming the standard for printers, and apparently they allow some good things that postscript does not. I've filed a bug on this here: http://bugs.winehq.org/show_bug.cgi?id=18741

Security and Usability:

The security team thinks we should finally start respecting the execute bit - this means removing all MIME handlers for executable code from the desktop and replacing them with a single front end for programs lacking the execute bit. This front end would notify the user of the problem, scan the file for viruses, and then present some information about the path towards execution. It is still undecided whether the program should allow execution outright, however from a UI perspective this would clearly be more efficient.

This creates a design challenge. In brief, we have to simultaneously manage expectations about Wine, inform the user that there are other (preferred) methods for installing software, not patronize them for installing a Windows program, tell them we scanned a file for viruses but that it may still be unsafe, make it easy to use, and make it hard to use accidentally.

After input from the community and discussion with other designers, I believe I have some good ideas for how to handle these challenges. The Canonical design team has agreed to integrate the UI extensions I've gathered into their weekly user testing, so over the next few months we should be getting some real feedback on the merits of various approaches to this problem. I'll be working more on this personally, and already have a good chunk of the specifications and front end code done (thanks to some great community help). I will, of course, share it here when it's in a usable state.

As far as we, as an upstream, are concerned, there's not much to change in Wine itself other than to keep making it work better and fix bugs. If I had to name one in particular, I'd have to say the "unclean removal of applications menu" entries is a particularly confusing issue for users.

What I'm doing:

Over the next few months I'm going to be working rather hard on the Karmic Wine Integration spec that I lead at the Summit: https://wiki.ubuntu.com/karmic-wine-integration. I'm still drafting the spec based on my notes and discussion, but at this point I have a very good idea of what I want to do.

Most of the code involved is directly relevant to the Wine user, however almost none of it needs to go into Wine itself other than some icons. At this point it's mostly python scripts, modifications of other python programs, and Glade dialogs. I may set up a BZR/Git repository of the various bits once they start turning into actual packages (which I'll also be doing).

Anyway, keep your eyes peeled, the next wave of distro releases are going to be very slick.

Thanks,
Scott Ritchie