On Tuesday 30 May 2006 01:17, Mike Hearn wrote: > As the Summer Of Code begins and new blood joins us all at once, > I thought it'd be a good time to open a discussion on how we are doing as > a project. > > Questions to consider: > > * Is Wine improving or is the regression rate matching the improvement > rate? > > * Are we producing a quality product, from the perspective of > non-technical end users? (I appreciate this isn't a goal for everyone) > > * Are we turning away potential developers for any reason? Could we do > more to attract new hackers? > > * Are the projects fundamental processes serving us well? > > * Any other thoughts for improvement?
Well, winecfg need more improvements to be really usable (ie. understandable) by a non-technical end user. Anyway we need to improve wine base installation: users should not have to always use winecfg to configure wine, many things must be detected at installation/runtime We must work on (free/gnome/kde) desktop integration too For developers, i think we miss (in wiki): - wine developer begining HowTo - wine comiting process (explaining why AJ never respond when patches are refused :p ) - simili-doxygen APIs (to found what is implemented/how/where some docs, and status) > > In case it's not clear, I'm talking about the project as a community > adventure here rather than technical aspects of the codebase. > > >From my own perspective I think Wine is doing better than ever before. > > What prompted this email is the realisation that in the past few days I've > used Wine nearly every day to run a variety of apps - from games to > utilities - and it's succeeded with every single one. Not always > perfect but always good enough. I am no longer surprised when Wine runs an > app correctly as I was when I first came to the project, these days I > nearly take it for granted. Though this may be due to having developed a > feel for what will work and what won't :) > > So clearly we're doing something right ... I also think we are doing OK > with attracting and keeping new hackers. The influx of new Direct3D talent > lately is fabulous for instance. The experiences of our SoC students will > be useful in assessing how to improve the learning curve and we need to > tap this resource better than we did last year. > > In other words, I think we're doing pretty well. I feel more > positive about the project that I have done for a long time. It seems like > as Win32 stagnated and slowed down over the past 6 years we've been able > to turn the tide and add our own code faster than Microsoft can, which is > the tipping point. > > So areas for improvement? > > * We seem to be doing very well in recruiting hackers who work on one > particular DLL or area and solidly improve that, but a less well > when it comes to 'general purpose' hackers who just take random apps > and make them work. > > It might just be that I'm out of touch but I don't see as much > patch traffic these days along the lines of "This patch set fixes > XYZ app" followed by 6 patches to 6 different DLLs. Discussion on > IRC/wine-devel is > > * 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 :( If you are speaking about wine-bugs task list, i think the wiki is more appropriate for that. It will be cool to have a time-line roadmap as trac (http://www.edgewall.com/trac/) > * Integration with other projects is still a weak area. Desktop/kernel/X > integration could all use some work. I know I know, I'm guilty in > not doing my bit here too .... maybe I will find my hack-fu returning > sometime soon and work on the fullscreen patch again :) :) > * App specific patches. Well I don't expect policy here to change anytime > soon but extreme cases like the WoW VMA layout problem which affects > tons of users do highlight the issue. For WoW the problem is really on WoW code. Proposed patch (who try to adapt VM layout) only works for part of users. I don't understand how blizzard made to handle their memory that way > * A few random things I already got into arguments about (forums, libwine > api etc) :) > > What do you guys think? > > thanks -mike Regards, Raphael
pgp1TQOkxaGlK.pgp
Description: PGP signature