Hi Sarah.
Knowing that you probably have better things to do than comment on a
fork, I appreciate the reply.
On 2012.06.07 16:57, Sarah Sharp wrote:
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.
Yes, unfortunately, there's a very long history of items that is
difficult to condense in an easily digestible manner for the benefit who
are only now alerted that libusb had issues. It's also difficult to
provide details without bordering on finger pointing, which, while
relevant, isn't exactly the kind of thing one wants to see discussed on
a technical and very busy mailing list.
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:
Sure.
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?
I guess the way we saw it would be a matter of having a majority of
maintainers voting for the addition of a new one. The criteria for
adding maintainers will of course primarily based on how much time
potential candidates think they can contribute to the review,
maintenance and integration process, as well as the kind of experience
they can bring. Of course, we also listen to our community when they
think someone should be added to the team, which is actually why we
currently have 4 maintainers instead of 3, as some of us originally
intended.
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.
That has been our main problem indeed. For more than a year, various
people have tried to reach a compromise with regards to the sharing of
power on libusb, but didn't manage to make it happen. From being the
most outspoken with regards to these issues, I have received many
requests to initiate a fork during that time, but always ended up
declining. I can also indicate that both Hans and I would have preferred
a more peaceful resolution. However, when it became clear that a fork
was about to happen regardless, we came to the conclusion that we might
as well support that effort fully.
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.
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?
As you may expect, we've been pretty busy with everything associated
with setting the project up (we're not completely done yet) as well as
trying to demonstrate through concrete actions that we can give libusb a
good run for its money, but those are indeed good points. I'll make sure
the 1.0.12 and subsequent releases get announced here, and I'll see what
we can do about LWN as well.
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.
It was sent to libusb-devel [1] (which you should be subscribed to),
with the expectation that this is of course the core group of people
that needs to be alerted to the fork. But I agree that we should
probably have CC'd this list as well.
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.
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.
We're hoping that, after a few major distros have ditched libusb in
favour of libusb (our recommended approach, as it is less confusing for
users), and we have build a strong enough base, this problem will
naturally resolve itself. From where I stand, I can only see very little
future in libusb unless its maintainership changes drastically.
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.
Ok, great! I'll dig your mail on the USB 3.0 BOS descriptor out of the
archives and reply to it.
Thanks. Looking forward to it.
With nobody having volunteered for the Linux implementation, I was
planning to see if I could do that in time for the release. But even
without BOS/SS_EP_companion support, we have enough features as it is
(as well as fixed a potential major Linux regression with pthread that
was introduced with 1.0.11), so we'll probably freeze to RC early next
week in order to reach the current 2012.06.15 release target. This means
that completion of BOS retrieval support for Linux is probably something
that can wait a little.
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.
Yes, I've seen that. I had an early look at lsusb to see what it was
doing in that respect.
Or are you going to be storing the descriptors in a
different format that would make it hard to share code with lsusb?
At the moment, our implementation only returns a raw BOS descriptor,
which is the concatenation of BOS header and Device Capabilities, as
described in the specs. We plan to add some parsing functions to
populate DevCaps structures, but most likely after we have added BOS
retrieval for most platforms (we also have OS-X and *BSD to take care
of). For the Endpoint Companion, as well as for all other structs, we
use the specs designations (bmAttributes, etc.), which is of course the
same approach as taken by lsusb, so I don't think there should be much
of a problem. There may of course always exist the odd non-specs
specified member, that eases the actual implementation, but it doesn't
seem to apply there.
Regards,
/Pete
[1] http://marc.info/?l=libusb-devel&m=133483162507983&w=2
[2]
http://packages.debian.org/changelogs/pool/main/libu/libusbx/libusbx_1.0.11-1/changelog
--
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
