> 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. As the open-source model of development goes, it's really up to the people that use the application to maintain it. That includes the developers from crossover, and anyone that uses wine. There are just too many applications, and subsequently too many features in those apps, to test before every major wine release. We do have a conformance testing system in place for the api though: http://winehq.org/site/docs/wine-devel/testing The problem is that we don't have enough tests, and we need more help writing new tests. The other problem is that it's very difficult to test everything about wine that could break an app, say for example whether a button is the right color or not. We can't really test that with automated tests. On Thu, 4 Nov 2004 09:57:14 -0800, Mark Knecht <markknecht@xxxxxxxxx> wrote: > On Thu, 4 Nov 2004 12:27:00 -0500, James Hawkins <truiken@xxxxxxxxx> 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 > -- James Hawkins _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
