4 new commits in master

[Pete Batard]

On 14 April 2012 13:27, Michael Plante <michael.plante at gmail.com> wrote:
>>> Sorry, but most forks seem to be proving you wrong here.
>
> Those projects are irrelevant to libusb[x].

Oh really? What is true to other forks won't be true to libusbx
because we are a "special case"?
The laws of gravity don't apply to us because we're different, right?

>>> > Where on earth did you get that?
>>>
>>> Simple:
>>>
>>> 1. "if we thought we could work with libusb, we wouldn't have forked"
>>> 2. "Not really true" (implying "we can work with libusb", which you
>>> explicitly indicate further down). "The problem wasn't a lack of
>>> commits, but a lack of releases." (implying the only problem there is
>>> with libusb is a lack of releases and that apart from that it's doing a
>>> good job.)
>
> I have no problem with 1&2 there.

Yes. And I have one with 2 if what you are stating is that you can
work with libusb and that I/we should too. So what do you want me to
do? Agree with you that I can work with libusb, when I keep stating
that I see a major problem in trying to do so, and that I see ZERO
advantage for us there, but only a repeat of the major drawbacks we've
seen for more than 2 years and that are the sole reason for this fork?

> It still seems you're making stuff up
> that flatly contradicts what I actually said one line earlier.

It still seems you're only seeing what you want to see, and ignoring
what I say. I disagree with you with regards to being able to work
with libusb, and that stems from directly trying to collaborate with
Peter over the past 2 years.

>>> Actually, I'm planning on stating that I'm not going to participate to
>>> libusb-devel any longer, after I announce the fork there.
>
>
> So I *explicitly* made a point about unsubscribing from libusb-devel, to
> which you responded.  Anything less is a complete change of subject.  Let's
> say for a second this is a typo or oversight and you do plan to unsubscribe.

Unsubscribe or not doesn't matter. If you look at my contributions to
libusb over the past few months, you will see that there's hardly any
message from me, and that libusb-pbatard is as good as dead. The fact
of the matter is you shouldn't see any more post from me in
libusb-devel. But I'm smart enough to keep my options open (you never
know). Now, if you don't see it that way, and consider that my point
won't be valid unless I unsubscribe, I'll be more than happy to
oblige.

> So someone will need to forward patches to your inbox.

Someone will need to forward patches to libusbx-devel, yes. I'm not
planning to touch anything that exists only on libusb-devel. Most
likely, I won't even bother reading it (since it's likely to free me
some time, which I would welcome) especially if unsubscribed.

>>> And what I did say is that I would pick up the patches from libusb I
>>> deem interesting and apply them to libusbx, so you don't have to bother
>>> about the above.
>
> ...that now becomes impossible, being unsubscribed and all.  Pick a side.
> :-P

I already did, but you don't think things throuygh. What about the
official libusb git repo? It's all that matter, because by the time a
patch exists there, it has been reviewed and approved so I don't have
to duplicate that work. That's where I plan to pick up patches, and
nowhere else.

If you have any other questions on how I plan to follow through with
what I stated earlier, I'll be happy to answer them, so that you can
comprehend that this isn't something I cobbled together in the last 5
minutes. I do very much have a plan. So please try to think that I
*MAY* have thought things through when I reply. It'll avoid a repeat
of these annoying threads where I have to elaborate on all the
elements you failed to consider (or that you deem unlikely, such as me
dropping from libusb-devel, which is a decision I took ever since a
fork was meant to happen), and that are the main reason for me taking
the position I take.

>>> Curious, I think Xiaofan indicated that he saw the need to choose a side
>>> too.
>
> No, because you were responding to your own statement earlier, "it's highly
> unlikely that contributors will waste their time submitting patches to both
> projects".  You proceeded to say, "he's been feeding items back and forth,
> and he's probably going to continue to do so".  Choosing sides is mere
> semantics compared to the original point about the actions on patches.

Notice how I used "items" and not "patches" in my statement. I'm not
wanting to diminish his contributions in any way, but Xiaofan does not
produce patches (apart maybe from a couple of elementary ones if I'm
not mistaken), so the "contributors will (not) waste their time
submitting patches to both projects" does not apply to him. The
contributor from the statement above is someone who produces code
patches from the git repo(s), as these are the only persons that
matters in *your* problem of wanting to keep libusb and libusbx close
in terms of code diffs.

So, I stand by my statement that Xiaofan would have been a better
example than Hans, but still not the one you are looking for to try to
prove your point.

> Taking sides makes both projects less successful (fewer eyeballs), unless
> everyone takes the same side.

In case you haven't noticed, it's forking that makes both projects
less successful. You're trying to get a fork without the drawbacks of
a fork. Well, that's called not forking, and we tried it already.

> And Peter, for one, will never take our side.
> So we lose his expertise.

Yes. And when Hans Reiser allegedly killed his wife the Linux
community lost his expertise. I'm sure he was/is a great technical
guy, but that doesn't detract from the fact that some bad deeds will
trump otherwise good deeds or qualities.

> I know you don't care for his review, when he
> occasionally chooses to offer it, but I do.

Peter has been a catastrophy for the maintenance of libusb, and
despite requests from many individuals, he has both refused to
acknowledge it and work on it. Whatever good qualities he may have
eslewhere, they are not enough to redeem his far more disastrous
actions for libusb users, and I will assert that this is the position
anybody who is serious about this fork will take (else, it really
doesn't make any sense to fork).

If you think they do, then please contribute to libusb only and ignore
this fork.

Regards,

/Pete