Suggestions for improvement of the emulator

[Mike Hearn]

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
   that.

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.

thanks -mike