Hi Jens, On 2014.01.27 12:25, Jens Bauer wrote: > On Sun, 26 Jan 2014 17:07:42 +0000, Pete Batard wrote: >> I, and many others, happen to think users of libusb deserve more than >> one release in 4 years, even more so as continuous major development has >> been going on. > > I disagree. > If libusb works fine, no need to fix bugs that are not present.
Shall I remind you that, the only reason people can run OpenOCD on Windows, using libusb (rather than libusbx) is that *we* pushed Peter, through the release of libusbx, to release his version of libusb 1.0.9, that was the first to include Windows support. If you followed his earlier dismissive comments on OpenOCD and elsewhere about the Windows backend being subpar, then you can only come to the logical conclusion that he would probably never have released otherwise (since there hasn't been any other release of libusb until this new one). So, you are basically implying that it was fine for OpenOCD to remain officially unavailable on Windows, until such time Peter felt that the Windows backend was to his liking. But in the same sentence, you also kind of prove my point that, if the Windows backend was as subpar as Peter makes it to be, you couldn't really be saying that "libusb works fine" for your purpose, since I don't recall seeing much complaint from OpenOCD Windows users on our lists. Furthermore, we also did fix some pretty major bugs since libusb 1.0.9 was released (please take a look at our Changelog). Or are you under the impression that libusb is a lot more stable and much less in need of development and bugfix than OpenOCD? You may have been lucky to never run into a libusb bug when using OpenOCD. But I think the vast majority of OpenOCD and libusb users will prefer relying on actual bug fixes, from an up to date library, rather than luck. > If the USB standard does not change, no need to change the library. Ah, but the USB standard did change, and we did add support for a bunch of newly introduced USB 3.0 constructs (BOS, etc). Also, if you are planning to use OpenOCD through an USB 3.0 controller on Windows 7, you very much want to use the latest libusb, as we have to regularly add the names of new HCD root hubs (which each manufacturer provides) into the library. Without this, you can forget about using OpenOCD through an USB 3.0 port. This is very straightforward low risk fix to add (and we actually did one of those in this release -> "VIA xHCI support"). Do you really want to tell Windows 7 users with a VIA USB 3.0 controller, and that want to use OpenOCD to access an FTDI device for instance, that they are MUCH better off waiting a couple of years for a "more stable" libusb release (whatever that means)? > Since libusb is a core library, I find it much more important that it stays > reliable. Which is our goal. Contrary to Peter's propaganda, we are committed to fixing, improving, and trying to make libusb more reliable. It looks to me like Peter seems to be under this weird impression that any software development that isn't under his direct control can only be rushed and have complete disregard for stability. But if your idea of stability, when there are very important bug to fix as well as much requested features to add (such as hotplug), is to only release once in 5 years, I think you are mistaking stability for immobility. > Each time there is a non-bugfix change to a library, there is a risk of > introducing new bugs. Should you advise the cancellation the next release of OpenOCD then? If not, it makes no more sense to be against this release of libusb as it is to be against the next release of OpenOCD. That is, unless you consider that, unlike OpenOCD ones, the current libusb developers and mailing list contributors are just a bunch of amateurs who have little clue on how to develop serious, stable code. But if that is the case, I will kindly ask you to try to back up what made you reach this conclusion with facts, rather than hearsay. > I'd personally prefer stable quality code over code that has features added > every day. Hyperbole. Disproved below. > OpenOCD is a good example; it's been an open wound for a while, but the > current developers are very serious and focus on fixing bugs, rather than > adding new features. OK, so Peter's propaganda has worked, and you are under the impression that the current libusb development team and contributors are NOT serious, don't care about bugs and just want to add shiny features. If perusing through the libusb-devel and libusbx-devel mailing lists is not enough to prove the opposite, let me show you our Changelog then, for 1.0.17 (libusbx, released 5 months ago) to 1.0.18, and which was linked in the announcement (http://log.libusb.info): 2014-01-25: v1.0.18 * Fix multiple memory leaks * Fix a crash when HID transfers return no data on Windows * Ensure all pending events are consumed * Improve Android and ucLinux support * Multiple Windows improvements (error logging, VS2013, VIA xHCI support) * Multiple OS X improvements (broken compilation, SIGFPE, 64bit support) 2013-09-06: v1.0.17 Apart from VS2013 support, pretty much ALL of the above fixes something that wasn't working (and some of these issues are very much present in libusb 1.0.9). Please cease to base your opinion on the false impression somebody else is trying to propagate. Use verifiable facts. > So I'd prefer that if there's a version of the USB library the has to be > changed often, that it would have a different name; it would be fine to keep > the name libusbx for this purpose, so that the name libusb would not deviate > from it's previous stable reputation. 1. RERO (Release Early, Release Often) doesn't mean unstable. Please look it up (in the Linux kernel for instance). 2. All of the current libusb and libusbx active developers want the merge, and it is also pretty clear that the vast majority of our users don't want to have to contend with 2 libraries that are essentially the same, except for the fact that one was frozen in time until now. Thus, if you want to try to prove your point that this merge is the harbinger of instability, please bring evidence. Regards, /Pete ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
