On Fri, Jun 8, 2012 at 2:15 AM, Pete Batard <pete@xxxxxxx> wrote: >> 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. > > I don't have any objection to that model. External impartial arbitration is > what has been sorely missed on the libusb project. Also, from having had to > step in as a libusbx maintainer against my will, I definitely wouldn't mind > being booted out of the position by a neutral third party, as it'd free up a > lot of my time... ;) > > I'll have to check with the other maintainers, but I really see no objection > granting Greg or Alan or any other trusted third party complete > administrative access to the libusbx project, to ensure a repeat of libusb > can never occur. As Sarah mentioned, libusb is an important part of the ecosystem, so I have no objection to grant Alan Stern, Greg KH and Tim Roberts the power. >> 3. How have Linux distros reacted to the libusbx fork? > > As was pointed out, Fedora is due to switch to libusbx and Debian is going > to switch in Wheezy as well, as you already found out [2]. Hopefully, there > are a few more to be publicly announced, but we haven't really had a chance > to follow closely on what the various distribution's plans are. > >> Are they >> providing both packages and marking that one conflicts with the >> other, or are they dropping libusb in favor of libusbx > > For the two distros above, it is the latter. > >> I see a note in the mailing list >> archives that Debian straight switched to libusbx, but how are the >> other Linux distros reacting? > > That's what we're curious about too. Right now, we're concentrating on > making sure that we avoid the pitfalls of libusb and produce a quality > library, that distros can have the confidence to switch to and not look > back. But what they decide is really up to them. Debian and Ubuntu libusb maintainer are the same person. I think it will be soon that Ubuntu switches too. Arch Linux: still under discussion https://bugs.archlinux.org/task/29999 >> 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. > > > The funny thing is that I personally would also have preferred (and proposed > at the time) something other than libusbx, which I also wasn't thrilled > about. My main concern was with ensuring that people looking for libusb > would also get search results that mentioned the fork, which logically meant > using a dash or or a breakable suffix in the fork name. Also, one > consideration is that the original libusb, currently uses a 1.0 API as well > as v1.0.x for versioning, and may therefore still want to reserve the > libusb-2.0 name for a future evolution. We are trying to compete fairly, > thus, hijacking libusb-2.0 could probably be considered a dirty tactic, as, > outside of additional information, users will naturally prefer 2.0 over 1.0, > regardless of the quality of the content. > > If there's a majority preference for a specific name, or a strong dislike of > libusbx, we can of course look into picking a different name. I think the name is not that bad and it is a bit difficult to change the name now that the infrastructure is there: libusbx.org domain name, Sourceforge project page, mailing list, and probably more importantly Linux distro's package name. I think we should change the name later, say after finishing 1.0.13 release and when switching to 2.0. -- Xiaofan -- 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
