wineconf and ideas
jasonp1 at cox.net
Wed Mar 20 19:35:11 CST 2002
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"
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
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
More information about the wine-devel