<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:10pt"><div style="font-family: times new roman,new york,times,serif; font-size: 10pt;">Hello<br><br>Thanks. These are good ideas. I hope I have done my best yet to support the developpers. I had already good feedbacks with patches to test against a wine version for fixing a certain problem. But also sometimes I don't have the time (other things keep me really busy) to make that wide testes. As far as I see that I can file a useful bug report with less than a half day I see to get the time to make more intense tests to get a good quality bug report. On other side, I also see bugs which are completely (or no fix replay) untouched since they where reported. See Bugs #<a href="http://bugs.winehq.org/show_bug.cgi?id=3599">3599</a> #<a href="http://bugs.winehq.org/show_bug.cgi?id=3611">3611</a> #<a
href="http://bugs.winehq.org/show_bug.cgi?id=3800">3800. </a>The other part is (and I think I'm not alone with this) that I can only maintain a limited apps at a time. There whould be much more apps to maintain (the ones I know from my daily business) but currently I don't have the resources to do this. So I hoped that I can start with a "most important list" and work on this list as maintainer until they are completely working with wine to go forward for new ones to get them working. But I noticed that I working still on the same count of apps. Maybe i'ts not important for all but here a small list of the apps which are regulary requested to be working on Linux (out of the box):<br><br> - Corel Draw 9-13 (much often, not just by myself)<br> - MS Office XP / 2003 (specially Outlook and Access) (sorry)<br> - MS Project (sorry again)<br> - Photoshop / Illustrator /
InDesign<br> - Adobe Premiere (I know its nearly impossible)<br> - Lotus Notes (6.5.x / 7.0)<br> - DentalLab XP (a small erp solution for Dental Technicans)<br> - The Nokia Sync Software for their mobiles<br> - Serveral Tools to feed GPS navigation PDA's<br> - Adobe Acrobat (Professional) (I don't know why)<br> - NavBox Pro Plan (Aviatics Application) (private pilots)<br> - PCMet (Meteo app for aviatices (private pilots))<br> - AustroControl (Meteo app for aviatices (private pilots))<br> - Pocket FMS (Navigation Software etc.)<br> <br>I know there are a lot of others which I cannot rember yet. It whould need to take a small survey but I know there are others.<br>I also know that for the most of the listed apps are good linux equivalents avialable. As I said before, its (my) goal
to bring the people frist to a linux desktop. switching from the windows apps to their linux alternatives can be made later when theyself recognize that the native linux app is more powerful than their windows version.<br><br>Roland<br><br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Urspr�ngliche Mail ----<br>Von: Robert Shearman <rob@codeweavers.com><br>An: Roland Kaeser <roli8200@yahoo.de><br>CC: wine-devel@winehq.org<br>Gesendet: Dienstag, den 11. Juli 2006, 17:17:55 Uhr<br>Betreff: Getting Help With Bugs (was: Re: AW: 0.9.17 and other issues)<br><br><div>Roland Kaeser wrote:<br><br>> <snip silly messages going back and forth about opensource><br><br><br>The following is not specific for you, but something I hope can help <br>others out that are in your situation:<br><br>There are a number of things you can do to make your bugs more likely to <br>be fixed by volunteer developers:<br>1 File a
bug!<br>2. Describe the bug accurately. If it is not completely obvious, <br>describe what the program should be doing and what actually happens.<br>3. Only describe one bug per bugzilla entry, unless you think they are <br>related. Doing otherwise will probably cause your second problem to be <br>ignored.<br>4. Provide debug messages printed when reproducing the bug.<br>5. Use a standard Wine configuration. This includes not mixing native <br>and builtin DCOM dlls and not using WineTools. In fact, try to use as <br>many builtin DLLs as possible.<br>6. Try to reproduce the bug in a freely downloadable version of the <br>application (for example, a demo or trial version) and provide a link in <br>the bug. (Note that having to fill in a form with details to download a <br>program puts me off trying to fix a bug, but others' opinions may be <br>different.)<br>7. If you suspect the bug is in a certain component due an error message <br>in a dialog box or on the console and you
know which debug channel it <br>corresponds to then attach a log of that debug channel to the bug.<br>8. Be repsonsive to developers asking for you to retest, try different <br>dlls and create debug logs. You can be pro-active, but be careful to not <br>be annoying. Deriding Wine or Wine developers is likely to be seen as <br>annoying and your bug will be ignored. Testing the bug on each release <br>of wine (or on a less regular basis) and reporting its status is <br>welcomed and will show that you care about the bug being fixed and that <br>you will be responsive if a developer investigates the bug further.<br><br>-- <br>Rob Shearman<br><br></div></div><br></div></div></body></html>