4 new commits in master

[Pete Batard]

On 2012.04.11 04:36, Michael Plante wrote:
> Renaming those files runs the risk of eventually making differencing more
> difficult.  If the files' contents change enough, git may or may not match
> them up with the libusb version, which will make it more difficult to copy
> changes back and forth.  Is there a good reason to rename them?

Yes. It's called branding, which is very crucial when you're new on the 
market and competing against an existing product. The more references to 
libusb we leave in our project, the less likely people will remember our 
name, and the less likely we are to succeed.

When you're called "Pepsi", it's really not in your interest to have 
"Coca Cola" mentioned anywhere...

As to making changes more difficult to copy back and forth:

1. Because we seceded from libusb (fork), we don't care about making our 
changes easier to apply there. If we thought we could still work within 
the frame of libusb, we wouldn't have forked. Remember that a fork is a 
very aggressive act, that pretty much implies breach of communication 
between the parties, since they can't come to a compromise on 
fundamental matters. Generally this also implies users of the original 
project taking sides, rather than trying to contribute to both. 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.

2. With regards to the opposite (libusb patches -> libusbx), it's highly 
unlikely that contributors will waste their time submitting patches to 
both projects, especially as since we're a drop in replacement, so you 
really have to pick whether you go with libusb or libusbx. As such, 
making it easier for general contributors to produce patches that apply 
to both is not something we need to bother with. The only people who 
should be concerned about picking up changes from libusb and whether 
they are easy to apply are the maintainers... Well, as a maintainer, I 
don't see much of a problem with patches that differ quite a bit between 
2 projects, especially as I now have good experience of doing something 
very similar with branches I maintain, and that get to diverge quite a 
lot (the trick is not letting oneself being constrained by git).

3. libusb and libusbx ARE going to diverge more and more as time goes 
buy. It doesn't matter whether the divergence is with the name of the 
file or the code line preceding and following a patch, it's pretty much 
the same. Therefore, if we start concerning ourselves with trying to 
reduce the difference with libusb, we're not going to get very far and 
we're actually going to make it more difficult for people to contribute, 
because they would also have to keep considerations in mind that they 
wouldn't have to do if participating in a regular project.

Regards,

/Pete