wineconf and ideas

[Tony lambregts]

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" 
>status.
>
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 
>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.
>
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.

Tony Lambregts