On Tue, Jun 14, 2005 at 04:15:41PM -0500, [EMAIL PROTECTED] wrote: > "Jim C. Brown" > > > >> Some of us do a bit more, by deliberately testing qemu with lots of > >> software, looking for bugs. And reporting bugs when they are found. > > > > If you really want a bug to be fixed badly, and you have no idea of how to > > fix > > it, what you need to do is contact the developer of that code and let that > > person know about the bug. > > That's not really practical, because most of us would have no idea who to > contact. >
I didn't think about that. I generally ask that on the irc channel, and get my answer there. Or I search the archives to see who was working on the code. But if there is no developer, it may take a lot of work just to find that out. > > > E.g. I'm the developer of the gtk2 interface for qemu, and I have no idea > > about > > what bugs it may have as no one has reported any to me. In fact, I have no > > idea > > if anyone is even using it because I get no direct feedback. This is > > especially > > true for using the gtk2 interface under Windows, because I am unable to > > test > > the code there. If someone who could test it did, and told me about the > > bug, > > I'd fix it right away. > > I do use the Windows builds... > > I'm willing to do some testing. But you'll have to tell me how to do the > gtk2 interface under windows..... > Well, you will need to apply the patches and compile from source yourself. Not to mention, you'll have to download the windows versions of the GTK2 libraries (you can probably get binaries). Let me know if you need clearer instructions. > The only interface I know of is the regular SDL interface in the windows > version. > They should look identical. Fabrice mentioned some SDL keyboard bugs, presumably you won't see those in the GTK version. I'll let you know now: Fullscreen mode won't work. The mouse will be grabbed (and made ungrabbable until you exit "fullscreen" mode) and the window will be moved to the top left corner of the screen. Otherwise, no difference (if my code works). Everything else should work identically between the two. > But yes, if you really do want somebody to test it, and do want feedback, > then I am willing to try. It wont be a major test for hours and hours kind > of thing. But I can play around with it for a while and see if there are > any obvious problems. > That would be great. > But it gets significantly frustrating when you see the same problems month > after month after month, etc. > Only report it the first time you see it. > Bug reporting tends to feel a lot like shouting in a room full of deaf > people... > > And bug reports get lost so easily. > > If you aren't the developer of that piece of code, what are the odds that > you are actually going to remember the bug in a few days? > If you are the developer, you will remember the bug. Otherwise, it doesn't really matter if you remember or not (in the sense that forgetting will hurt things). > > > No one looks at the Savanah bug tracker because its never been used. If > > you were > > to say submit every unfixed bug you found there, just maybe those of us > > who > > bother to look every once in a while will see it and fix it. > > I have thought about it. > > I've even started to do it a few times. Come to think of it, I even did > that a few times in the past year. > > But since it's not used, and none of the developers suggest it being used, I > tend to get the feeling that it'd be a waste of time. > > Right now, there are 50 bugs reported, and 50 bugs open. > > http://savannah.nongnu.org/bugs/?group=qemu > Some one of those bugs have actually been fixed. A patch was sent a while ago that got rid of bug #9441 IDE multimode failure. (Long before the bug itself was submitted.) So was the gcc 3.4 bug (which includes a link to the patch). Etc. I have to take that back. Savannah bug tracker is not a good way to go, as e.g. even if the bugs are fixed none of the developers can say so or close the bug. Only Fabrice has access. Also, only he has commit access so good patches, such as the graphics patch, don't always make it in right away. Still, not enough developers have had issues with the way Fabrice runs things, so thats not likely to change. > > > Do this often enough and others will use it, etc... the qemu user forum > > and > > the qemu irc channel developed in much the same way. > > The qemu user forum does get regular comments about bugs etc. > > About the best we can tell them is something like "Yes, that looks like a > bug. No, it probaly isn't going to get fixed any time soon. No, most of > the qemu developers don't visit here." > Yes, more communication is needed. We shouldnt be bothered by bugs which have patches to fix them or bugs that are a non issue or bugs that are easily worked around, and users should be able to find the answers to this easily. But I am not entirely sure why this is not the case right now, so I have no bright idea to suggest. Someone else will have to fill the void here. As a side note, I have a hackish patch that will allow you to change the cdrom in the monitor to a filename that includes spaces. It was not a difficult change to implement. I don't see why you couldn't have fixed that yourself (if it hasn't already been fixed in main CVS). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
