Jean-Michel Pouré - GOOZE wrote: > Just remember there was a peer discussing about a 60 second timeout bug > in libusb/pcscd. The first peer says "the bug is in libusb". The second > peer says "the bug is in libccid". And the bug never gets fixed. And ALL > tokens may suffer from this 60 seconds timeout. > > Peter, as you are a peer of libusb, maybe you could comment on the 60 > seconds bug and explain why it was known and unfixed for more than a > year.
As far as I know this bug was first brought to the attention of the libusb community unrelated to anything libccid or pcscd, in an email from Graeme Gill, who also suggested a solution. In his first reply the maintainer (Daniel Drake) confirmed the problem, and raised several important points after reviewing Graeme's suggested solution. 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. In one sense Graeme had fixed the bug already, in another sense he left it up to members of the libusb community to pick up the problem description and the suggested solution, and resolve the problem on their own. Daniel's reply came less than 48 hours after Graeme's report. Five months later, the ccid maintainer created http://libusb.org/ticket/56 including a forward-ported version of the revised suggested solution, still without documentation. Daniel's involvement in the project was slowing down, he had made me co-maintainer, and I was busy being overwhelmed by quite many and quite difficult practical details of adding Windows support. There was no further significant feedback on the ticket until one more tester confirmed it working. I did a round of review and provided feedback on what I found important. Two months later you commented in favor of including the patch. There still didn't exist any documentation, and noone had taken any action based on my review. Several months later, Hans de Goede being paid by Red Hat partially to work on libusb stepped up and not only brainstormed a resolution for my concerns, but he also created documentation for the new APIs. Given this, the fix was included in libusb.git master. In the time between each of the above events everyone involved was obviously also working intensely on many other matters, possibly perceived as being more important, possibly because of the lack of feedback in the ticket, or because of lack of further reports of the same problem on the mailing list. On behalf of the libusb project I would like to express a sincere thank you to you, for testing and commenting in support of the patch! At the same time I expect you to understand that unless you or someone else produces a perfect patch according to peer review standards then you must accept that others will work for you in their own time exclusively when they choose to do so. This is a very important aspect to understand about open source software. Open source only works if you take responsibility for every single line of code that you are using. > Really this would help understanding the concept of peer review. I hope my recount helps. Feel free to ask further! (As it happens, everything I wrote above is clearly visible either directly in the libusb ticket which you commented on, or in emails linked to from comments in the ticket preceding yours.) I don't believe that anyone in the libusb community has ever suggested that the problem would be in the ccid package. I don't know who you quoted above. There was always a way for the ccid package to work around the problem, I don't know why this wasn't done, but I guess that it would have required too much effort, and noone contributed such effort to the ccid project. I guess that a perfect patch for ccid would have been most welcome. > I am not against the concept itself, just I don't know how to arbitrate > between 2 peers and handle a project of 100.000 users with only 2 peers. > > This is mostly what happened to OpenSC lately: bugs and fixes were know > BUT 1) not applied 2) not tested in beta by a large number of users. I hope you realize that 2 drives 1, not the other way around. > we need the help of a broader community. Don't hold your breath. Noone will work for you. If you want something you have to do the work. And more importantly you have to do the work exactly the way your reviewers want it. > In a large community of users (>10.000), leveraging on Internet, > you can help you find and chasse a lot more bugs. You seem to be in favor of pushing code to users without developers first making every last effort to discover and fix all problems. I think that development model is reckless, irresponsible, and an insult to users, other programmers, and software in general. Open source not having deadlines and thus not requiring code changes in a hurry is exactly what allows it to work as well as possible when it arrives to the user. > Let us give time to see how the new architecture based on Gerrit and > a packaging farm works. Time will tell if this is efficient. Gerrit and Jenkins have little to do with development itself. They do simplify tedious processes and remove a certain amount of manual labour, which is not to be underestimated, but the key point is that tools don't take the place of humans doing code development. If you want development to happen, then you can do development. It is actually as easy as that. If you had done libusb development that would have helped libusb ticket 56 to get closed sooner, and if you do OpenSC development that will help make OpenSC better faster. It will equally help with any and every other issue you may have had in the past or will have in the future, with any and every open source project. I recently saw a nice quote from Linus: I'm a big believer in "technology over politics". ..in response to a question about Linux patches from Microsoft. Article: http://www.linux-mag.com/id/7439/ I agree with him. It's difficult to argue with perfect patches. However, when patches are anything less than perfect, as they often are, then the responsibility to perfect them lies with the contributor. //Peter
pgpVkejF8V7uK.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
