On 2013.06.29 13:02, Peter Stuge wrote: > Xiaofan Chen wrote: >> Take note now that libusbx/libusb will be merged > > Xiaofan, please hold off on reporting about the future until it has > actually happened.
For the sake of people following this list, since there is a complete agreement between ALL of the maintainers of libusbx (of whom both Xiaofan and myself are members) as well as the new maintainer of libusb, let me restate: libusb and libusbx _will_ be merged sometime after the release libusbx v1.0.16. It's not a question of if, it's a question of when. > Statements like "now that so-and-so said that such-and-such will happen" > amplify expectations based on something that hasn't really happened > yet. Announcing a future course of action, that has been universally agreed on, so that users (such as OpenOCD developers) have a better chance to prepare for it if needed, is exactly the kind of practice one should expect from an Open Source project. It's a bit like announcing planned release dates. Of course delays can happen, and for the time behind, we haven't set any target for the first re-merged release, but when the maintainers of 2 projects announce a planned course of action, there is usually a very high probability of it happening. > It can of course be helpful for libusb-1.0 API users to know the > latest news from the hostile fork (their words) libusbx Ever stopped to wonder why libusb has had to experience 2 "hostile" actions in a row (the libusbx fork, and then Nathan having to cut you out from libusb maintenance), and why both of these were directed at circumventing the uncompromising attitude you have with regards to how the project should be conducted? > but as I > have always stated, and contrary to what libusbx developers > communicate, I think there's really nothing more important than to > maintain API compatibility as far as possible between forks, even if > some new APIs make no sense. How nice of you to say that. Remember how you single handledly, and without any consultation, decided to break the versioning API right after libusbx had its first _public_ release, by introducing your own incompatible version in libusb, in an action that couldn't more effectively demonstrate the statement you just made above to be utter bullshit? Heck, we had to fix the libusbx API in the next release so that libusbx remained compatible with the obnoxious and unnecessary breakage you introduced (so much for us not caring about API compatibility). Libusbx has always taken great care to make sure that our library was compatible with libusb. On the other hand, the first and _only_ release of libusb that occurred under your 3 year reign as a libusb maintainer was one that "didn't maintain API compatibility as far as possible between forks". So I hope you'll excuse me for, once again, relying on your actual actions (or lack thereof), instead of grandiose statements about "perfect code" and whatnot, to form an opinion of what you actually stand for. > There are known issues with libusb-compat-0.1 on Windows, someone > just needs to work on fixing them. Yes, that would be nice. Then again, you may also understand that developers can be quite put off trying to contribute to projects where "release" seems to be a taboo word and where proposals go months/years without being either dismissed or integrated into mainline... For what is worth, both the libusb-devel and libusbx-devel mailing lists will welcome fixes for libusb-compat-0.1 on Windows. Regards, /Pete ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
