How are we doing?

Raphael fenix at
Tue May 30 04:09:27 CDT 2006

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 

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 

> 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 

>  * 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url :

More information about the wine-devel mailing list