wineconf and ideas
tony_lambregts at telusplanet.net
Wed Mar 20 20:43:08 CST 2002
Jason Phillips wrote:
>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"
Yes we should be using bugzilla. I sort of gave up on it because nobody
was using it and it looked like it applied to codeweavers wine and
comp.emulators.ms-windows.wine was the official place to report bugs..
We need to improve bugzilla and stop using
comp.emulators.ms-windows.wine. Its the only way to get the QA that we
need. We need to integrate the app database into buzilla and have a
"maintainer" for each app. That even useless bug reports (xyz crashes
when I do this) can be usefull if the right person sees it.
>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.
This would be good to have.
>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
I agree with you completely here. With less than 100 Dovelopers
fragmenting wine is not a good option. Lindows is free to do what they
want , but if they want to see wine work sooner they would be best off
to not have a private tree. Just my opinion.
More information about the wine-devel