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.
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.
- 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.
- 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
At 05:35 PM 3/20/02 -0800, Jason Phillips wrote:
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.
Why would they submit anything to the LGPL fork? Lindows can't use code from the LGPL. So they probably and hopefully are gonna submit code to the X11 fork, which was WINEs original license btw... Thus the LGPL fork is certainly not the official Wine. In fact, after the fork we have now at least two "official" WINEs...
Roland
On Thursday 21 March 2002 11:16 am, you wrote:
At 05:35 PM 3/20/02 -0800, Jason Phillips wrote:
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.
Why would they submit anything to the LGPL fork? Lindows can't use code from the LGPL. So they probably and hopefully are gonna submit code to the X11 fork, which was WINEs original license btw... Thus the LGPL fork is certainly not the official Wine. In fact, after the fork we have now at least two "official" WINEs...
Roland
First of all, my bad for even mentioning anything license related. Let's call truce before Brett Glass shows up. ;-)
The main point though is that it takes code contributed back under either license, or both, to benefit wine. There's no reason why this can't be done. Many companies have worked under the model of contributing to open source projects, e.g. Cygnus and gcc, RedHat, IBM, etc. And CodeWeavers is already doing this for Wine.
Why should it be done? Well, like Michael R originally pointed out, a single company working on their own fork of the code is going to have a much harder and more expensive time than using the "communal" one used and developed by anyone freely/openly. That's the "trick" of open source projects: high visibility of bugs, common standards, and widespread support of developers worldwide, etc. And actually, Wine had a different kind of license before it switched over to X11, the one that starts with a G. Something I learned at the confernece...
-
Jason Phillips -
Roland -
Tony lambregts