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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
