Hello Johannes, I have to admit that your post did piss me off a little bit. But on the other hand it would not help anybody, if I would shoot back, so I will try to be as polite as possible.
My first note is on your first message, which I really have not received. It is probably my fault, but I would have answered it, if I had got it. I did read it now in the archive - so sorry for that. If someone would seriously claim that well structured source code needs no comments, I would say he is an idiot (it is as stupid as the "You have to switch to Microsoft Terminal Services, then." answer), but I'm *not* calling you an idiot. In fact I belive you were a little far-reaching in defending Fabrice's work. If you would lean back and lock from some distance to the current usb cvs source code (except usb-uhci.c) you will admit, that it is a quick and dirty work. This is not, as you suggested, nasty to Fabrice. Sometimes it is much better to implement something as a quick and dirty job than to not implement it at all. I do *really* appreciate Fabrice's work. You made some assumptions about large patches to linux. First of all you compared apples to oranges. A initial usb support patch as was introduced to qemu between version 0.7 and 0.8 would never have been accepted into the linux kernel. (-> quick and dirty work) so on the other hand there would have been also no necessity for me to submit such an large patch. On the other hand there are or at least were these large patches to the linux kernel, when a new device or device class was implemented. In most cases these large patches are now first tested on some other kernel tree and discussed there. But for qemu there is no such other community. You have a great talent to pick examples. (the ones about usb_device_add ...) You will probably find some source lines where I have made such changes without any good reason, but the ones you have cited here are not of that category. The "product_name" change was introduced by Lonnie Mendez (read his post about that) and I think they are ok. It's nothing someone should be required to discuss long about, there is no reason not to rename them. The other example you have choosen is the one I have changed with my last patch which I had submitted with the documentation. The reason for this patch was simply that there were two "usb_device_add" functions (same name different functionality). Last but not least I have to tell you, that I do not like the way you are looking at open source development (at least what you have revealed in your last post). There is no way of telling people what they have to do or what they shouldn't. You can politly ask them, if they would change something, but you can't order them to do it and you should never ever try. If you ask someone politely to do things in one or the other way (like Fabrice did) you have to be alerted that someone will refuse to do so (as I did). I said no because I could not imagine how I should do it (there are some exceptions, read below). If someone else thinks he can do it. Then it is his task to stand up here and show that it could be done. I have a lot of doubt if it is possible to reach the same consistent, well documented and good structured source code. But I really would like to be proven wrong, we all would win on that. I'm aware that this applies also to me and my patch. I can not tell you to commit this patch I only can ask you (politely) about that. If you refuse to do so, it is absolutely ok. That was the point when I had said: "Sometimes you have to take what you get." There may be things which can easily be extracted from the patch. One of these things Fabrice picked up already (usb-hub.c). The other files are (usb-libusb.c) and (usb-bsd.c) this saves around 1000 lines of the patch. But it does not do any harm to add them to a large patch, as I did. The reason for adding them was that I work with usb-libusb.c all day long and it would be great to have this file in the cvs tree. The file does do no harm and does not mean significant more work to the person who is applying the patch. There is also a other reason why I have included it, to make it easier for people outside the cvs applying process to test the patch with different os platforms. With kind regards, Tino H. Seifert _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
