On 5/29/06, Mike Hearn mike@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