Just wanted to say I had a really interesting time at WineConf2002. Mucho gracias to Lindows for their generosity in hosting it. I'm pretty much new to wine so I got a lot out of it, and it was great meeting the Wine developers in person.
Here are a couple of points that I would really like to agree with about what was already mentioned that's needed for Wine. 1) Use the winehq bugzilla. There are only something like less than 500 hundred bugs in reported so far. I'm sure that the number of actual bugs is dozens of times more than that. Also bugzilla lets people know who's working on what, what issues are being worked on, and other information that makes it easier for newcomers. Something that wasn't really mentioned but maybe should be is to let there be more of an established process in how bugs go through their cycle. Normally that's largely the role of QA and in an open source project QA is one of the less "fun" roles, but it's still needed. For example, I submitted a patch that fixed a bug and I'm now curious how and when that goes to the "closed" status. 2) Create the unit/regression tests. In Xtreme programming I vaguely remember that writing the unit test is the first step before actually writing any code to clearly define the technical requirements and also verify that it does what it needs to do. I can see the value in that, even though it wouldn't be practical to take it to that level. Possibly as an idea, there could be two levels of tests. One, more of a sanity test type check and another which would be much more rigorous and lengthy for regression and unit testing.
Making a few tests is something that I could start with right away. Wineserver seems an interesting place to start doing stuff and poking around, but I don't want to get in too deep right away. Besides I heard there's already work being done on it in some way (hint: if it was in bugzilla I'd know exactly what's being done and by whom). Maybe I'll do a developer type doc on wineserver and how it all works as I figure it out for myself.
Michael Robertson commented on how wine could attract attention by focusing on a top 10 sort of list. That seems like a good idea. That's one of Lindows' main goals anyway, right? Maybe they could start submitting bugs from their own testing. If Lindows want's to make a substantial difference in Wine development why don't they hire more than 2 developers devoted to it? Working off of and submitting to the official LGPL Wine source would also obviously be a great help too. Having a proprietary code fork doesn't really help the official Wine out that much, especially if it's never merged back in.