4 new commits in master

[Pete Batard]

On 2012.04.14 15:53, Xiaofan Chen wrote:
> Unsubscribing libusb-devel is not necessary a good thing. The
> experts there (Tim Roberts, Alan Stern, etc) are very good resources
> to make use of.

And I expect them to subscribe to libusbx if they are interested and 
comment on matters that are of interest to libusbx if they want. I don't 
see an issue there. Alan and Tim and others are already subscribed to 
quite a few lists.

I do not expect them to comment on libusbx matters in the libusb mailing 
list, and I certainly would not want them to, since our activities are 
meant to be independent and we have a fully functional mailing list. 
Just as is the case when people post a question about libusb-win32 on 
libusb-devel, or an item may be of interest to both, I expect that, if 
people have data that they think is of relevance to libusbx, either 
someone will point them to copy libusbx-devel or forward it themselves 
(which is something you already did).

> I think they will be neutral to the fork

Yes, and IMO people not taking side is the main reason why libusb is in 
the impasse it currently is. From his latest posts on that subject, 
Peter still seems convinced that I'm the only one that has an issue with 
his approach to maintenance. If Tim or Alan had picked a side, maybe 
libusb wouldn't be in the quagmire it is now. Segher also tried to stay 
"neutral" for a long time, by eluding the question as to whether he 
would accept to be a maintainer if the position was offered to him, 
which was very detrimental to the health of the list. I think if 
libusb-devel has proved a point it's that keeping neutral does not solve 
any problems.

> and that is one
> of the reason why I think libusb-devel can well be the best place
> for libusbx discussion as well, not libusbx-devel, at least not for
> the short term.

The sooner people use libusbx the better. People are smart enough to 
participate in more than one list if they want. Moreover, if someone 
proposes a patch on libusb-devel and gets no reply, they may be more 
inclined to switch to libusbx and instead propose patch there (which 
they may have to redo, as they would when moving data between 
independent yet similar projects). Trying to have a clean separation 
between libusb and libusbx is not entirely innocent. I see it as a good 
way to attract disgruntled contributors to our shores. The only issue is 
they have to be aware of libusbx is one way or another... which can only 
happen if the awareness of libusbx is raised through branding or other 
means. The other oprion is to hijack the libusb-devel mailing list as 
you proposed, but I find that a bit disingenuous, so I'm personally not 
planning to do that.

>> If you think they do, then please contribute to libusb only and ignore
>> this fork.
>
> I am not so sure what you mean here. But I do not see a problem
> to let Michael try to contribute to both libusb and libusbx.

I don't see a problem with that either. But I do see a problem with 
Michael wanting libusbx to care about libusb and keeping the gap as 
small as possible, so that *his* participation in both project, which I 
don't anticipate many people doing, is made easier.

That is selfish and I see it as detrimental for libusbx users at large, 
since keeping libusb in mind for every minute detail *will* drag us down 
and reduce our impact. If we go that route, it'll make people consider 
that participating or using either project is basically the same, when 
what we want to make them realize is that libusb has no future and that 
they would be much better off switching to libusbx.

Regards,

/Pete