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
