wineconf and ideas

[Jason Phillips]

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.