On Thu, Jun 7, 2012 at 9:27 PM, Sarah Sharp <[email protected]> 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 [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libusbx-devel
