Suggestions for improvement of the emulator
mh at codeweavers.com
Thu Sep 8 17:07:17 CDT 2005
On Tue, 06 Sep 2005 21:29:22 -0700, Juan Lang wrote:
> This is frustrating, and some people do seem to be put off by it. I have
> no idea how many potential contributors we lose this way.
FWIW, I share these concerns though given my non-existant patch writing
speed lately I'm not sure how much my opinion counts here ;)
Let's take a few examples of patches that were rejected but I feel ought
not to have been:
* System tray patch. I wrote this when I was 18, I'm now 21. It's taken
over three _years_ and this patch is still not deemed correct. In the
intervening three years our users have constantly asked why the system
tray simply does not work for them.
I have no idea what is wrong with this patch. Rob tried to get it merged
too, again, he came away empty handed. Last I remember, Alexandre felt
the desktop integration code needed better design, or more precise
design, or something but I'm not really sure what. I don't care anymore,
long since given up on this one.
While I'm all for getting desktop integration right, I don't feel the
system tray is so vital that it's an all-or-nothing scenario. It doesn't
need to be perfect first time around, it needs to work and make our
users happy which by and large it does (did?)
* Delay logging. This is the patch where you could press set an
environment variable and then F12 would toggle logging on/off. It's
helpful when the debug output is so verbose it prevents you getting to
the part of the app that is buggy. IIRC not merged because it was
putting policy into the core code, or it was felt a system based on
piping/awk etc would achieve the same thing. I don't remember which but
at the time, I remember showing that the performance benefits that
motivated it didn't stay with a pipe/awk based approach.
Yesterday a newbie Wine hacker was asking how he could debug an app
given that he couldn't reach the buggy part with debug logging on.
Needless frustration for new developers! Exactly what a project facing
manpower issues doesn't need.
* Building winetest by default, despite it crushing less powerful machines
(gas really hates trying to assemble 20-30mb of input). The reasoning
given was that otherwise it might bitrot or fail to build, but we
already have automated systems to compile winetest that would notify us
if it failed to build. At the very least it could be a configure option.
Now, like everybody here I have huge respect for Alexandre and the work he
does. I could not do it. But, I agree with Troy and Juan here. I see no
reason not to push parallel branches or version control systems as a way
to scale up the project.
This would have two simple benefits:
1) It would allow sub-maintainership of certain DLLs, if we wanted to do
2) It would add some flexibility to the system so that if Alexandre
makes a bad judgement call, it's possible to notice (because patches
he rejects are being merged in to other trees, or vice-versa).
This is what the kernel project does, and it works well for them. Linus
tends to be quite conservative, so other maintainers can merge in more
risky patches and find out if they work.
At the very least we should try and do more to attack the 90 degree
learning curve associated with Wine development. Documentation is good
but it seems nobody is really working on pulling new developers in any
more. A sentiment I've heard echoed in the past is that Wine is just hard
- well, it *is* hard, but then so is kernel (technical) and GNOME (user
interface) development yet these projects have many developers. We should
try and figure out why.
More information about the wine-devel