On Thu, Jun 7, 2012 at 9:27 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > Hi Pete, > > Thank you for providing the libusbx side of the story. I know this > kind of email can be hard to write, and hard to respond to. > > It sounds like working with the libusb maintainer was pretty frustrating > on both sides. I understand your need to fork, given the slow release > cycle of libusb. However, I'm going to avoid analyzing the community > issues you had in the past, and instead focus on the future of libusbx. > I have four community-related questions that I hope you can answer: > > > 1. I'm glad to hear that libusbx has four maintainers. The more > eyes that are reviewing code and merging changes, the better the > code is, in my experience. Have you defined a process for adding or > removing libusbx maintainers in the future? It seems like you > really want to avoid a repeat of the issue you had with the libusb > maintainer not wanting to give up power. > > My suggestion is that you allow nominations for maintainer addition > or removal from the community through the libusbx mailing list. > When someone seconds a nomination, everyone on the list should send > a private yay or nay vote to an unaffiliated third party, like Greg > KH. That third party should have the rights to add or revoke commit > access to the libusbx repository, so you can avoid the case where > the last-standing maintainer doesn't want to remove themselves. You > could probably just copy the Debian community voting model. > > With a formal voting process in place, the community can have an > anonymous say in whether they want to add or remove a maintainer. > How does that sound? > > > 2. Was there ever a libusbx announcement on the linux-usb kernel > mailing list? Have you asked LWN to run an article on the fork? > I can't recall ever seeing an announcement, although it may have > gotten lost in my inbox. > > It's pretty important to rope in the USB kernel community for a new > userspace USB library. If you haven't sent an email detailing the > project's homepage, mailing list, and maintainers, I suggest you do > so. If you have, please accept my apologies for missing it. > > > 3. How have Linux distros reacted to the libusbx fork? Are they > providing both packages and marking that one conflicts with the > other, or are they dropping libusb in favor of libusbx, or are they > sticking with libusb only? I see a note in the mailing list > archives that Debian straight switched to libusbx, but how are the > other Linux distros reacting? > > I'm concerned that any work that's contributed to libusbx won't > actually be available for distro users. If the libusb release cycle > is as slow and problematic as you say it is, then any changes made > to libusb won't be available either for quite some time. This > leaves users needing to get releases from the git repo, which is > less than ideal. > I guess fedora is moving to libusbx. http://hansdegoede.livejournal.com/12524.html and https://bugzilla.redhat.com/show_bug.cgi?id=823886 for details. > > 4. (This is really just my opinion, feel free to ignore it.) > Would you consider a rename of the project? libusbx looks like a > misspelling of libusb to me, and since they are both sourceforge > projects, it's very easy to confuse or mistype the mailing list > address. > > "libusb2.0"? "libusb-future"? "libusb-active"? "libusb-fork"? > "flibusb"? Actually, I kind of like "flib" usb. :) > >> For what is worth, libusbx provides a publicly accessible roadmap [1] >> and, depending on our sorting out USB 3.0 BOS retrieval support (which >> could actually use a Linux contribution [2], and which is the result >> of yet another patch submitted to, but never acted on by libusb more >> than a year ago), we should be on track for the next release which is >> planned around the middle of the month. > > Ok, great! I'll dig your mail on the USB 3.0 BOS descriptor out of the > archives and reply to it. BTW, would it make sense to share the BOS > parsing and printing code with lsusb? lsusb already has support for > getting, parsing, and printing both the SS endpoint companion and BOS > descriptors. Or are you going to be storing the descriptors in a > different format that would make it hard to share code with lsusb? > >> [1] https://sourceforge.net/apps/trac/libusbx/roadmap >> [2] https://sourceforge.net/mailarchive/forum.php?thread_name=4FCCA5E3.8080101%40akeo.ie&forum_name=libusbx-devel > > Sarah Sharp > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
