Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch

[nix . wie . weg]

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