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 _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
