On 2012.05.15 04:42, Peter Stuge wrote: >> if you want to dismiss the Windows backend as full of bugs > > I never wrote that and I never hinted at that. > > This email thread is about just one bug.
Quote: "the Windows backend doesn't really deliver because of this bug and with a few others". >> fixing this is likely to be a waste of time when we could spend it >> on implementing the full hotplug. > > ..if you don't mind having unfixed bugs. ...or if you don't recall how new enum came into existence, as part of a TWO step process aimed at introducing hotplug, for which we have had a proposal for almost 2 years now. Excuse me for "knowing" that the current enum process was really designed to being used with a libusb(x) library that also provides hotplug, and therefore that features that have close ties to hotplug may not be implemented with the first part but instead will be with the second. >> since you "know" so much about the bug, you should easily be able >> to tell what these circumstances are then... > > I will not bother telling again There's no "again". I'm talking about new data here, which I don't recall having seen pointed out before, with regards to how some tests may be more representative than others to highlight the issue at hand, and therefore why my earlier test may have produced different results than what was logically anticipated. > since you don't consider it receivable. > (Hint: Uri, Hans and me have already told you > several times now.) Even if we don't seem to be talking about the same thing here, when a very verifiable initial test appears to disprove the issue as it was presented, with nobody pointing out a potential flaw with regards to the test process, it will of course be what is used by the maintainer(s) to determine whether they think a fix is receivable or not. Had my initial test replicated the issue Uri and Hans highlighted, I would have applied the patch, but the problem is: it didn't. Therefore, whether you want to consider it receivable or not, this logically changed whole outlook with regards as to whether this could be considered as _generic_ an issue as presented (i.e. one our users were expected to run into even without doing much of anything special) or something very specific that would only apply to Hans and Uri's custom implementation and that may therefore be better left off libusbx altogether. If we want to confirm that there is a problem, then the first thing we'll want to do is try to find a logical explanation for the apparent discrepancy between my test and the result from Uri's app, which is also something I tried to do, and which is also part of what led me to conclude that this patch might be better left off. Now, while I stated that I didn't see the need to apply the fix, due to the above, I still invited for more data to be presented to challenge my conclusion, with a very prominent "if you can modify xusb or produce a sample that demonstrates that your issue occurs in a non custom hotplug scenario, that's a different story", and which Uri has now provided. So I still don't see anything subjective with regards to my determining whether something was receivable or not. The only thing that is receivable is data, and, unlike Uri, you haven't provided any that aimed at "confirming" your presumption that this was a bug. What's more, you completely disregarded data that very much seemed to prove otherwise. Thus, if you actually wanted to be helpful and prove your point, you probably should have tried to point to some missing element from my test, and why it may have failed to highlight a potential bug, as it would have helped cut this whole discussion short, but you didn't. Or does it still not bother you that there exists a test, that attempted to follow a potential bug's replication steps exactly, yet that didn't highlight a problem, or that, as I stated, it is also very much possible to use Uri's patched xusb and get the expected results after installing the driver for devices that are very much reported as "UNSUPPORTED"? You're of course free to consider that verifiable data is woefully irrelevant when trying to prove your point. But please be reminded that there are still some of us who will attempt to use it as a receivable proof, when trying to reach their own conclusions. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
