On 2012.09.30 01:04, Chuck Cook wrote: > From my point of view. I would like to see libusb-1.0 go through > another iteration or two.
I definitely want that too, and I'm happy that Hans has agreed to do it. If I had more scope, I wouldn't have a problem maintaining both branches, but right now, I'd rather not promise something that I don't think I can hold. > Remove the dependency on WinUSB and the other dlls. Removing the WinUSB dependency would be a cool project, but it would basically mean reverse engineering the DLL and creating our own open source version (albeit part of the libusbx DLL rather than as an independent one). Great when you have the time, but probably not so much of a worthwhile effort when the DLL is already there on most platforms (Vista) and resources are scarce. Now, removing dependency on the K dll is something we have already agreed we'll try to do, as I also mentioned earlier (And we should be able to sort license incompatibilities). But since this cannot exactly be qualified as an urgent matter, it will probably take a while before we spend time on it. > One core issue that I see as a need to be addressed. Is a set of tests > with baseline devices which exercise all functions of every API on every > platform. No final release until all the test boxes are checked. > Problems are being fixed, but are we introducing new ones? I've _started_ to create a testing wiki page: https://github.com/libusbx/libusbx/wiki/Testing I actually did that before your post, but soon got depressed at the idea of how long I could make that table grow... The one problem I see is, comprehensive unit testing is fine on paper, when you have the resources. But I seriously see us having a major constraint in that domain, and right now, I see rigorous comprehensive unit testing as utterly unrealistic. Just to give you an idea of the variations we would ideally want to test on each release - Linux, OS-X, MinGW, MSVC, WDK, cygwin, BSD - gcc, Clang, MSVC with memory leaks detection, WDK with OACR, cross compiling - 32 bit, 64 bit - Mass Storage, Composite, HID, other - USB 2.0, USB 3.0 (including various proprietary USB 3.0 controllers on Windows) - Control, Bulk, Interrupt, Isoc - sync, async, single threaded, multi-threaded, timeouts, etc. - WinUSB, libusb-win32, libusb-win32 filter, libusbK - Windows 7, Windows 8, Windows XP - external apps such as usbutils, OpenOCD, libusbK benchmark - apps using libusb-compat - shared, static lib - libusb vs libusbx interoperability (for 1.0) Personally, I'm going to set the limit of what I'm ready to test for a release to 20, and I can EASILY pick 20 from the above for Windows alone, while being pretty sure that it will leave a major part of libusbx/Windows still untested. Oh and anything autotools on Windows takes forever to build (order of magnitude slower than Linux or OSX), so this needs to be taken into account as well. Regards, /Pete ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
