How are we doing?

[James Hawkins]

On 5/29/06, Mike Hearn <mike at plan99.net> wrote:
>
>  * Is Wine improving or is the regression rate matching the improvement
>    rate?
>

It's hard for me to answer this question, because I don't regularly
run many apps with Wine, but it seems like we've had reports of a lot
of regressions lately.  A bigger issue is how we should deal with
regressions.  Most of the bug reports we get are of the type, "This
app used to work, now it doesn't..." and we have to ask the reporter
to run a regression test.  I know these tests are crucial, but they
take a long time and many users don't bother going through that
process.  Even more integration with the AppDB might help with this
process.  Ideally we would like to inform the user of a "Last known
working release", which would be the Wine release that worked with
this app.  Looking at a sample AppDB entry, I guess this would be the
Testing Results->Wine Version->Runs? field.  If the 'regression'
keyword is provided for a bug, and the bug is linked with an app in
the AppDB, we could provide the "Last known working release" info to
the tester, so they know where to start testing.

>
>  * Are we turning away potential developers for any reason? Could we do
>    more to attract new hackers?
>

It seems a lot of developers are frustrated by our development model
(one pathway to commit) and by the amount of effort it takes to get a
patch committed.  I say too bad for them.  We have a great devel model
that substantially reduces the amount of bugs and bad code getting
into CVS.


>  * Any other thoughts for improvement?
>

One of my biggest concerns about the wine development process is lack
of direction.  A lot of the experienced devels know what they plan to
do on an individual level, but it's hard for people new to wine to
grasp the whole picture of what needs to be worked on.  We have TODO
lists, 1.0 goals, and janitorial tasks etc., but sometimes those items
lack meaning, even to me.  I really enjoy reading KDE's feature plan
page [1].  They list in detail what exactly needs to be
implemented/fixed.  One could say that we have a different development
model, in that our goal is to get application x, y, and z to work, but
that model is inefficient, and we usually don't work that way anyway.
There are features that are missing, important bugs that need to be
fixed, and it would be great if we could all take the time to list
somewhere, probably on a wiki page, the most important things that
need to be implemented/fixed.  On a larger scale than individual bugs
and features, we could also list dlls that need more attention than
others, e.g., ole32.dll is more critical than cards.dll.  As Dmitry
pointed out, test cases are very important to the devel process, and
typically they aren't very difficult to write.  Maybe we could have a
list of areas that need more testing.

Looking at wiki.winehq.org, I don't see anything that shouts out,
"Hey!  New to Wine development?  Check this page out."  I'd like to
see a one-stop shop that eases a new developer into the process.  We
could point them to the devel documentation, provide some beginner
tips, and show some areas of Wine that they can work on to dip their
toes in the water (Janitorial, tests, etc).  I'm sure there are lots
of new developers that decide they want to work on Wine, stop by, and
leave because they have no idea where to start.  Granted they should
put more effort into it, but it wouldn't hurt to cater to these new
developers.  We can always use more devels, right?

[1] http://developer.kde.org/development-versions/kde-4.0-features.html

-- 
James Hawkins