How are we doing?
fenix at club-internet.fr
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
> * 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
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060530/ada5d964/attachment-0001.pgp
More information about the wine-devel