On 2014.01.26 07:47, Peter Stuge wrote: > I've removed the libusbx-devel list since Pete Batard banned[1] me > after I wrote that I considered the libusbx code to have a bug[2].
Here we go again. Well, we've been through that quite a few times already. In the thread you pointed, I explained why this didn't qualify as a bug. A bug is something you don't want to happen that you overlooked whereas this limitation was a conscious design decision, and I explained, twice, why it was in place. In that same thread, I also offered, if you wanted to do something a bit more productive than just jump around and cry "bug" (as you previously did for items that ranged from alleged issues that someone never got around to report to us, to features that had not been implemented), to submit a patch that would help the user. You chose not to do that, but instead persisted in the unhelpful antics that got you earlier warnings that you could be banned ([1], [2], [3], which are a direct result of a stream of other non-helpful libusbx related posts you made to various mailing lists). So you were banned because it became clear that you weren't using the mailing list as a means of helping users, but as a means of trying to scare them away from the project, as well as undermine it. > I do however not think that it was appropriate to give an ultimatum > and remove me from the SF project, even if I wasn't responding to > emails, even for quite some time. The libusb-devel mailing list, and your own inbox, should be littered with posts from people (not just myself and Nathan), who, for many years, tried to reach a compromise with you, to no avail. As painful as it may be, one has to recognize when the diplomatic solution just isn't working, and when action needs to be taken. > I think the decent move would have > been to work on libusbx under the name of libusbx. But we're past that. 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'll of course continue reading both libusb and libusbx lists, but > since Pete and Nathan have made it clear that they don't think I can > contribute to what they do I'll continue to work on my own. You are free to provide constructive criticism, by pointing exactly to the section of codes you think have issues, and proposing patches to address them. As we have tried to make clear repeatedly, our objections stem from you not doing these things when pressed to do so. > What has in fact happened is that libusbx developers have taken > control of the libusb project on SourceForge and, as Pete describes, > have now simply renamed libusbx to libusb. > > That's of course not a merge. That would be true if you could name one active libusb developer that can be counted as being opposed to the merge of libusbx and libusb... But more than anything I can write here, the git history from http://git.libusb.org/?p=libusb.git speaks for itself. > What I *will* however do is continue to work with the libusb.org code, > website and community, as I have for more than 10 years. And you have all our best wishes with that, really (for that matter, we're not planning to do anything to the old libusb tarballs you are currently linking to, from libusb.org, and that belong to the libusb SF project). Competition is welcome, as long as it produces results that can be used. > It doesn't show much, libusb.git hasn't seen commits for a long time > and I have many unreplied emails, but I am still here and work is > still ongoing, if slowly. There are changes coming to the git repo > as well as some kind of release looming. Allow me to quote a post of yours that is very relevant to this discussion then, since this is the very rebuttal you gave when we announced that libusb and libusbx would merge [5]: "please hold off on reporting about the future until it has actually happened." > It's true that libusbx has bug fixes and new features which aren't > yet in the libusb.org code but it's also true that the libusbx code > has technical issues caused by bad implementations and bad design, Then, for the last time, please point to them. > both of which I don't want to include in the libusb.org git and which > I work on removing from libusb.org code in cases where it already > exists. Great. If we think you fixed actual bugs, we may pick some of your changes, as we've done in the past. But if it boils down to deciding, on principle, to annoy existing users by removing convenient features that have already been integrated and used, as you have also done in the past, we may pass... > there's more than enough bad software in the world already There you go again, trying to covertly qualify libusb/libusbx as "bad software" without pointing to anything concrete that made you reach such a conclusion. Just to reiterate, this actual name calling of the libusbx project is one of the many reasons you were banned from libusbx-devel. As long as you aren't trying to judge a beauty contest, please try to bring facts to a discussion. > I indeed do not want to help the libusbx project move forward, > which Pete makes sound as if I have refused to support libusb. The libusb project, is defined by the SF and github repositories, as well as the mailing list. It now contains code that was merged from libusbx, so it is a continuation of both libusb and libusbx. If you don't wish to work with this code, which is your choice, then the logical conclusion is that you don't wish to support the official libusb project. > If you want unfinished new features and some poor design choices Links please. Also, since when is a project only meant to include features that are 100% finished and polished, especially when they have been explicitly tagged as EXPERIMENTAL when introduced. > If you prefer a carefully, albeit slowly, maintained codebase then > you can remain confident with the libusb.org website and code. If > you are affected by any bugs then please get in touch. Kind of have to wonder why you have to beg users to report bugs to you, when, if libusb/libusbx was as bad as you indicate, you should just have to take your pick from the various mailing lists... > more important than fixing libusbx's API mistakes. Links please. > I've had less motivation for libusb after having dealt with Pete's > propaganda within the libusb project, the hostile fork he has led > tireless slander, Links please. > ad-hominems Links please. > name calling Seriously: please provide a link to an instance where this happened. If you cannot back any of the above up, it's a bit difficult to give credit to much of anything else you say. > I can not deploy libusbx code in production because of the issues > with the code Links to production deployment issues, please. > and libusbx maintainers do not share my concerns, Well, it's hard to address issues when they have not been demonstrated to affect anything but your imbued sense of what "good software" should look like. A short article on how, according to you, libusb can crash and burn when deployed in production, that points to some relevant code sections, would go a lot further and be a lot more helpful for all our users, than haranguing the crowds to try to rally them to a cause you now seem to be the last participant of. Regards, /Pete [1] https://sourceforge.net/mailarchive/message.php?msg_id=29662133 [2] https://sourceforge.net/mailarchive/message.php?msg_id=29822678 [3] https://sourceforge.net/mailarchive/message.php?msg_id=29822679 [5] https://sourceforge.net/mailarchive/forum.php?thread_name=20130629120205.29263.qmail%40stuge.se&forum_name=openocd-devel ------------------------------------------------------------------------------ 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 OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
