4 new commits in master

[Pete Batard]

On 2012.04.12 05:32, Michael Plante wrote:
> Very few people will think twice about those filenames, and we need to weigh
> that against the problems renaming creates.

Which, as far as the MSVC project files are concerned are minimal. 
Please don't overblow a simple libusb.sln -> libusbx.sln rename.

>>> 1. Because we seceded from libusb (fork), we don't care about making our
>>> changes easier to apply there.
>
> But we do, at least for now.

Because we are in the initial phase. We just forked.

> All of the Linux and OSX experts are still on
> libusb, and we need their contributions.  Maybe eventually we'll have them
> subscribed and convince them to take our side -- that is optimistic and then
> we can rename and it'll be Peter's problem, not ours.

Well, I think you are misunderstanding the intent of a fork is if you 
don't realize that it very much *requires* people to take side.

If people currently on libusb don't choose between libusb and libusbx 
(XOR), or consider the fork as benign as you seem to be considering it 
("Well, I'll just contribute to both") then libusbx is clearly not going 
to go anywhere.

By wanting to contribute to libusb, you're basically saying that you 
think that Peter is doing a good enough job, which very much implies 
that you basically don't see a reason for the fork.

Once again, a fork is no benign matter, and that's why it has taken so 
long to get one on the rails. You don't participate in a fork if you 
still think the original project has a future.

We forked because we thought that libusb was going nowhere. And the 
assumption is that everybody on the fork will think the same. If not, 
then I would kindly ask people who are uncertain about which side they 
should take to leave this project and go back to libusb, because 
otherwise I don't see how they're going to help make sure libusbx is 
successful.

Forking IS hostile and arises when all possibilities of compromise have 
been exhausted. If you still see the possibility of a future compromise, 
you're clearly not gonna help this project as much as you should.

> But we are forcing a
> problem on someone, regardless.  And for what good?

Ensuring that people take side, rather than contribute to both which 
will result in libusbx being stillborn, because if most people 
contributing to it still see libusb as "good enough", libusb will remain 
the main contender.

>>> If we thought we could still work within
>>> the frame of libusb, we wouldn't have forked.
>
> Not really true.  The problem wasn't a lack of commits, but a lack of
> releases.

So releases don't matter? By all means, please go back to libusb if you 
think that is the case, because it seems you believe that libusb is 
doing fine then.

If you see a lack of releases as a minor issue (and ignore the fact that 
Peter has also repeatedly refused to share power, refused to answer 
critical questions as well as repeatedly went against the will of the 
majority), then clearly you think it didn't warrant a fork of libusb. 
What are you doing here?

>>> If I
>>> thought we could still have a nice exchange of patches between libusb
>>> and libusbx after the fork, I wouldn't be participating in this fork.
>
> I think this is a false choice?

And I think you don't understand how a fork is supposed to work.
You choose between KDE or Gnome. You don't contribute to both and hope 
they will merge back...

It seems to me you are indecisive about which of libusb and libusbx you 
should pick. And that's the actual source of your problem. If you 
embraced one and ditched the other, this whole renaming of the project 
files wouldn't matter to you one bit.

> patches WILL be exchanged.

And people WILL always be free to do whatever the heck they please with 
any project. That doesn't mean we need to endorse it.

>>> 2. With regards to the opposite (libusb patches ->  libusbx), it's highly
>>> unlikely that contributors will waste their time submitting patches to
>>> both projects,
>
> Counterexample:  Hans already has been doing exactly that.

Except this occurred when Hans thought libusbx was dead, since Segher 
was MIA. As long as libusbx is moving, I very much doubt that Hans will 
spend much time feeding back patches to libusb. Bad counterexample.

Xiaofan would have been a better example, as he's been feeding items 
back and forth, and he's probably going to continue to do so. Just like 
yourself, I wish he would pick a side and drop the other, because I'm 
genuinely concerned about how much someone who still sees libusb as 
having a future is going to invest in libusbx, but that's not something 
I can enforce. But as long as his mediating activities don't negatively 
impact on libusbx (i.e. he's not going to butt in about making it easier 
for the *SPECIAL CASE* of easing up the production of patches that apply 
to both projects), I'm not going to have much of a problem with it.

> You are making it unnecessarily difficult to do so in the
> name of "branding".

Branding is only one part. Ensuring that people take sides, so that our 
project strives is another.

>>> 3. libusb and libusbx ARE going to diverge more and more as time goes
>>> buy.
>
> Yes, but certain files don't need to do so very much, like the project files
> or the threading emulation, for example.

Then pick a side. If you want to serve both libusb and libusbx suit 
yourself, but you'll understand that this will be seen as a position 
that is detrimental to libusbx, because you will clearly still harbour 
the thought that libusb may come off as the better project in the future 
and won't invest as much in libusbx as you could.
I'd rather see you use the time you'd invest in making sure that a patch 
can easily apply to both libusb and libusbx into producing a 
libusbx-only patch that will improve our project alone.

Regards,

/Pete