4 new commits in master

[Michael Plante]

Pete Batard wrote:
>> 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...


Very few people will think twice about those filenames, and we need to weigh
that against the problems renaming creates.  It's not like the origins of
libusbx are a secret or something.



>> 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.  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.  But we are forcing a
problem on someone, regardless.  And for what good?


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


>> 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?  (Of course, Peter won't submit them here,
and I think you're probably the only one here who won't submit there, if
that's what you mean by "nice", but patches WILL be exchanged.)


>> 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.  And it was my
intent to do so as long as I could manage, assuming I had anything worth
contributing.  You are making it unnecessarily difficult to do so in the
name of "branding".


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

Regards,
Michael