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