[Wine]Crossover and Free/Wine

Mark Knecht markknecht at gmail.com
Thu Nov 4 11:57:14 CST 2004


On Thu, 4 Nov 2004 12:27:00 -0500, James Hawkins <truiken at gmail.com> wrote:
> > So, if so many things work on wine-20040213, then
> > how come so many things do NOT work on wine-20041019???
> 
> During the course of development and adding new features, bugs are
> constantly introduced.  It's the nature of the beast on such a
> large-scale project.  While we do try to limit any bugs going in, it
> is impossible to spot them all especially when a feature here might
> interfere with a very important feature over there.

James. Thanks for the reply. I am a hardware development guy who works
on VLSI designs with millions of logic gates. I completely understand
the design & debug process.

What I do not understand so much about most Linux development flows is
the apparent rush to release without verified testing. While I am
absolutely sure that I do not see what goes on behind the curtain, it
really appears to me that there isn't a consistent -APPLICATION- based
test procedure happening with the standard version of Wine before each
monthly release. If I am wrong about this then please correct me, but
I cannot find information on that.

It seems that users are left to discover whether the latest is
actually the greatest. This does not instill confidence.

On the other hand it is very clear to me that the Codeweavers folks
have their core base of supported apps and they don't intentionally
release a new version of Crossover office that breaks operation of
those apps. They make mistakes, I'm sure, but they also put off paying
customers with updates when they say they are not ready. I respect
that.

It's my thought right now that the open version of Wine *possibly*
lacks this part of the release discipline, but again it could be
because I just haven't found the info, and if that's the case then I
apologize here and now.

As a hardware developer I understand that when doing chips we cannot
release a design that doesn't work or it costs us millions and
millions of dollars. It is my hardware bias that leads me to see
software design (not only Wine but even here in Silicon Valley) as a
development area where *many* designers don't feel the need to be so
confined since 'code is easy to change'.

> 
> > I'd like to support the effort, but it's hard to learn
> > and hard to make an impact at my level.
> 
> The best way is to just jump in and start trying to fix things, even
> if you don't know how at first.  You'll send in initial patches that
> will probably be turned down, but you'll learn a lot doing this.  An
> easy thing you can do is regression testing.  If a feature works in
> 20040213, then you quasi-binary search to find the patch that
> introduced the bug.  Once it is found, you can either try to fix it or
> at the very least just let everyone know which patch is causing the
> problem.  Check out this link for more info:
> 
> http://winehq.org/site/docs/wine-devel/cvs-regression
> 

First, as is clear by now I think you should understand that I'm not a
software designer and am not going to even attempt to read code
looking for fixes.

I am recently trained in the Wine regression testing process due to
great help and patience from Duane Clark. I hope that over time some
of this effort will get linked up with a developer who can fix things
and is willing to work on fixing the things I find.

We'll see how it goes. 

Again, I understand how the Linux development flow generally goes.
I've been around it for the development of the Linux 1394 stack, as
well as a few of the audio apps. If this couple of messages seems
overly please don't take it that way. I really am impressed with all
the things that do work, but I can also see areas in which I think the
overall development program could benefit from some structure and
discipline.

Just my 2 cents...

- Mark



More information about the wine-users mailing list