How are we doing?

Wed May 31 18:15:28 CDT 2006

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"

-- 
By By ...
      ... Detlef