"Magosányi, Árpád" wrote: > > Graeme did some rework of the patch, but generally did not seem to > > agree with the review. The new solution included the addition of new > > API calls, however without any documentation. As anyone who has > > looked at the code and doxygen output, libusb is quite well > > documented, so the lack of documentation was obviously a problem. > > We are talking about lack of some documentation vs. a serious > useability issue.
As I explained, it was not and is actually still not evident in the libusb community that the bug was particularly serious (ie. that it was happening very often and/or for very many) since there was neither much activity following up on the original report, nor in the ticket. There has been significantly more activity for many other things. The way to address this is obviously not to shoot the people engaged in such other activity, but to make sure that your important message is heard loud and clear, when you have one. There have even been commercial inquiries for libusb-related projects, but none for this ticket. I am not saying that commercial inquiries drive my work on libusb, but they do indicate what matters to some others. > Have you noticed it yet? I'm not sure what you mean? I personally have not experienced the bug. Yes, I use ccid, although only occasionally. > > Open source only works if you take responsibility for every single > > line of code that you are using. > > Open source only works if you understand both the technical and > management issues. I am talking about what users have to do to make open source work for them. You seem to talk about how you wish projects to do management? This list is not about libusb development and I only tried to reply to the direct question about peer review for one particular libusb bug. Obviously there is much more detail to the libusb story than I can possibly write in a way relevant for OpenSC. I'm happy to discuss further in another more fitting media. #libusb on IRC or direct email or libusb list seem good candidates. > The operational words being "working" and "small" here. I would very much appreciate if you study the work that has been done on libusb by me and other contributors in the last three years or so, before starting to talk nonsense about small work units. Unless you invest this time for thorough research I'm afraid you aren't in a position to make any remarks on the topic. I'm sorry if that sounds harsh, but if you've done the research I am convinced that you will see my point, and I will be more than happy to continue discussing off this list. > It can be argued that a feature and its documentation are two > different work units. No, not really, not for a library where documentation is otherwise quite complete. > You will find out that leading a succesfull open source project have > much more to do with effectively motivate people to do the work than > being a good programmer, and sometimes aiming for the perfect code is > the slowest way to get good code. I don't know about you, but I'm not at all interested in "success" if it means having to settle for mediocracy in software. "Success" means nothing if the software we output is anything less than the best we can do if we really apply ourselves. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
