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
--
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
