Am Dienstag, den 30.05.2006, 00:17 +0100 schrieb Mike Hearn:
Thanks a lot for starting this. As I'm connected with wine about a Year now, I give my comments / feeling here. (It's large, but i'm unable to Split ...)
Questions to consider:
- Is Wine improving or is the regression rate matching the improvement rate?
Depends on the Area, and how the Wine improvements are validated by regression Tests. We have hundreds of Tests failing on various Windows Systems, and this is really bad. Many reasons for the regression rate is the fact, that we have no regression tests at all for many Functions.
- Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
It seems, that we produce a quality product, when an a widely used, previously untested Application works 'out of the box', but IMHO, we fail, because we have lot's of bugs (and regressions: missing tests) that stay unfixed for a long time. Can we get an overview with "new bugs" / "still existing bugs" / "closed bugs" per month from bugzilla (without duplicates)?
- Are we turning away potential developers for any reason? Could we do more to attract new hackers?
I was starting with wine, because i want to get my Lexmark X5130 working on Linux and my Idea was: Use the Windows-Driver with wine. When I started development with winspool, we had only 2 regression-tests.
It was very hard to get the first Patch accepted: I needed to learn, how windows works in this area, how CVS works and what was expected from a fine Patch. I read a lot of Documentation (wine-dev-guide, wine-wiki.org, winehq.org, MSDN and the Wine-source), got a lot of hints on wine-devel and finally my first Patch was accepted. (Great to be a Member of such a large Project.)
During the Time, things changed and I get confused more and more times about "special Developers" and "other Developers", as well as "special Patches" and "other Patches". (It's also Possible, that i did not see the big differences before).
I aware of the fact, that some Developer earn there Money when working on Wine, working on a special project with a Company behind them (wine on macos / Codeweavers as example) or others stay already a long time with Wine and all of the resulting special Patches are handled a bit different.
Some Examples from my point of View: EnumMonitors (Test + Implementation) needed a long Time: - I created, tested and send a Patch - No commit, and no comments for my Patch for almost two weeks - I ask for comments and got one Hint from one Person. - Updating, testing and resending the Patch - next week waiting again without a reaction. - Asking for comments: One Hint from a different Person - loop again > 5 times I was frustrated that it need so many loops from the first Patch for the tests upto the commit of the last Patch for the Implementation due to the fact, that I got only one Hint after every Update. One Hint was changing NO_ERROR to ERROR_SUCCESS. Another Example was to split the ANSI-Implementation and the UNICODE-Implementation (together ~11kb)in two Patches.
Here a Code-Review that I did: 1: http://www.winehq.org/pipermail/wine-devel/2006-February/045163.html 2: http://www.winehq.org/pipermail/wine-devel/2006-March/045278.html
A Test from Stefan Dösinger: http://www.winehq.org/pipermail/wine-cvs/2006-April/022105.html
I have no Idea about d3d, but the test-style is very Strange. Various tests in this Style (I created the Line-Wrap) : + /* Check the results */ + if( !comparefloat(out[0].x, 128.0 ) || + !comparefloat(out[0].y, 128.0 ) || + !comparefloat(out[0].z, 0.0 ) || + !comparefloat(out[0].rhw, 1.0 )) + { + todo_wine ok(FALSE, "Output 0 vertex is (%f , %f , %f , %f)\n", out[0].x, out[0].y, out[0].z, out[0].rhw); + } + else + { + todo_wine ok(TRUE, "Output 0 vertex is (%f , %f , %f , %f)\n", out[0].x, out[0].y, out[0].z, out[0].rhw); + } + I wanted to comment the patch, but it was already in the Tree. My only Idea is: "special Patch": @codeweavers.com
Big Patches went into the tree:
Juan Lang: crypt32: Implement CryptBinaryToStringA and CryptStringToBinaryA.
When I saw the big Patch, i wanted to ask to split this in seperate Patches: 1x Header-Changes 2x Testcase (2 tested Functions -> 2 Patches) 2x Implementation ( 2 Functions) However, the Big patch was already in the Tree: http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html
My only Idea is: "special Patch": SoC
Problem with this Patch: Functions not Present every crypt32.dll
Emmanuel Maillard: winecoreaudio: Initial Audio Driver for Mac OS X I saw the Patch and asked about the Project: Merge all sound-driver to "dlls/wineaudio.drv" Reaction: Resend a Day later after a comment from Alexandre and in the Tree the next commit-day: http://www.winehq.org/pipermail/wine-cvs/2006-May/023277.html
This Patch needed a bunch of fixes, done by Alexandre another day later: http://www.winehq.org/pipermail/wine-cvs/2006-May/023295.html
IMHO, every other Patch with a bunch of warnings will never pass. My Idea for this "special Patch" (wine-macos)
Is the Project for a single "wineaudio.drv" dead?
- Are the projects fundamental processes serving us well?
- Any other thoughts for improvement?
In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase.
- A Mentor for a new wine - developer, that tries to Guide the "new blood" a bit. (Vitaliy Margolen did a lot for me by commenting my Patches, when I started dev. for wine. Many Thanks!) - Merge the Coding Hints from wine-wiki.org, wiki.wine.org and wine-dev-guide - Wine Roadmap: Update the ToDo-List for 1.0 and Create a ToDo-List for post-1.0 - "Contributing to Wine" is really large and complex. I would suggest a small Welcome-Page that has: - Importand Headlines from the actual Page, - an invitation to join wine-devel and say Hello, I'm new on wine, - Link: "More Details for Developer" - Link: "More Details on Documentation and Localization" - Link: "More Details on Translations" - Link: "More Details on Application testing" - Link: "More Details on Artwork" - The Wine Party Found. The Links go to something that we have now in "Contributing to Wine" It's IMHO important, that the user does not need to scroll the Welcome-Page
With the Welcome-Page and a Mentor, we should get more developer to wine.
The other Side is the limited Bandwidth of Alexandre. For the Direct3D - Group, it's great, that they manage to test the Patches even if they sometimes fail (the double code-move)
We need more Groups like this. The Group from Dan Kegel, wo worked on richedit, was great.
It might help, that we state in the Patch, on which machines / OS the Patch was tested and which other Persons tested the Patch also.
- No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :(
Yep.
- A few random things I already got into arguments about (forums, libwine api etc) :)
- The number failures on Windows for our regression Tests must go down fast
- We need more Regression tests
- Maybe use parts of the SoC - Money, that Google give to the Project as Bounty for special Bugs (2398 OpenGL in a window or DSOUND-Buffer underrun as examples) or start a small "Wine Winter-of-Code"