On 2012.06.05 19:01, Peter Stuge wrote:
I'm the libusb maintainer since a little less than two years.
<snip>
As one of the maintainers of libusbx, I can't help but find the overview
of the libusbx fork given by Peter deceptively one sided.
Therefore I feel obligated to to provide some kind of counterpart. As
you may guess, because it deals with the reasons behind the libusbx
fork, the content below has of course have very little to do with the
technical issue at hand, or its resolution. Therefore, if you don't care
much about why forks happen, feel free to ignore it (or you can just
head to http://libusbx.org for a less controversial and more succinct
overview).
As to providing a short introduction, that compares with Peter's, I'll
just state that I also have been a regular contributor of libusb, for
more than 2 years now and I can also safely state that I invested at
least as much time in it, though I don't really feel it should matter much.
Now, with the matter of why libusbx actually forked from libusb:
- More than being the result of one person not getting along with Peter,
the libusbx fork was actually spearheaded in late 2011 by an actual
majority of libusb contributors, who had grown more and more tired of an
ever delayed release. As such, you may be pleased to know that we have a
bit more than 4 people onboard. Of course, with contributors and
developers always being in short supply, if any of you want to drop by
and give us a hand, you are more than welcome.
- Likewise, you shouldn't be fooled with what can only be construed as a
polarizing mention of Windows. In as much as Peter was reluctant to
accept the position of libusb maintainer, as the main libusb/Windows
contributor, I have been equally reluctant to accept a position as
libusbx maintainer. This is due in part to anticipating that it could
result in people mistaking or mislabelling the fork as a Windows centric
project, or a mere topic-branch. In short, unlike what Peter states, I
didn't actually spearhead the libusbx fork. I only happened to become
one of its maintainers after two of the original Linux maintainers we
had (Segher and Vitali) had to move on to other endeavours. In that
respect, libusbx is really as much Windows or Linux centric as libusb
is, and with 2 of our 4 current maintainers being Linux developers, I
don't think there's much concern to be hadt.
Now, since Peter's presentation of libusbx has been exceedingly
selective, I have to pursue with some less than pleasant exposure of his
responsibility, for what can only be described as a complete breakdown
of the libusb integration and release process, and which is what left us
with no other alternative but to fork.
- As Peter only partially touched, libusb does have a very critical
issue with having only a single maintainer, who has difficulty
contributing the adequate focus to the project (we're not only talking
solely about time here). The problem however is that, as far as trying
to spread the workload has been concerned, and despite many requests to
add more maintainers, with more than one capable community endorsed
candidates ready to step up, we encountered a major hurdle in what can
only be described as Peter's extraordinarily reluctance with having to
share power. With the previous maintainer having long left the project,
there has unfortunately been no arbitration or majority vote to be had,
and at least as far as the people behind the libusbx fork are concerned,
we can't exactly state that libusb is helmed by a benevolent dictator
either, which is one of our major issues.
- If you look closely at the 1.0.9 release of libusb, you should spot a
few alarming details: First, this release happened 2 years after the
last one, despite many critical patches having been reviewed and
integrated during that time. For an healthy project the size of libusb,
this is astounding, especially as libusb is still missing important
features such as USB hotplug events, and can't exactly be considered
mature a this stage. As a result of this delay, non-git users have been
left stranded, distributions have had to start maintaining their own
libusb branches, and overall people found themselves wasting time,
whereas we have now demonstrated that a release could easily have been
produced. Another disturbing aspect of the 1.0.9 release is that it
occurred without any form of preliminary announcement, let alone a
proper Release Candidate, despite its 2 years delay. Instead it popped
up right after the libusbx fork was officially announced. Finally, some
of the major patches that were added to this release were developed
internally by Peter and never submitted for review, which isn't exactly
the first time such a feat occurred and should be telling of how much
his alleged disagreement with libusbx, in an attempt to place a strong
focus on review, can be credited...
- Also, with regards to Windows being the reason of the 2 years delay,
stemming from a "problematic development effort", I can easily dismiss
such a statement as preposterous, with the sole intent of using Windows
as scapegoat for obvious maintenance failures that would be difficult to
brush off otherwise. For what is worth, we have had quite a few very
competent Windows contributors on libusb-devel, who did comment, review
and test the submitted Windows patches and didn't report much of any
issue with them. On the other hand, the actual integration hurdle we've
been having can only be described as Peter trying to impose a very
specific and uncompromising vision, which hardly anybody else appeared
to share, and which we have established as hugely detrimental for the
libusb community as a whole. One flagrant example of such behaviour
could be Peter single handed removal of HID support from the Windows
backend (once again without any form or community review) against the
wishes of the majority, not on account of a technical issue, but because
it just didn't fit what he had in mind.
Thus, if we are to believe Peter's statement with regards to Windows
integration being the main delay, one can only be astounded that, in a
matter of weeks, libusbx was able to complete what libusb has failed to
do for more than a full year, yet without sacrificing the review and
testing process. And with the Windows code having seen little change
over the last 16 months, we can also safely assert that the same effort
could have happened at any time during that period, within libusb, had
there been a real wish from its maintainer to see it happen.
- Finally, you may want to consider for a moment that there is still no
roadmap for the libusb release process or any upcoming features
integration, and you may also want to take a look at how long patches
are being kept open there. You may also find that, during his time as
maintainer, Peter almost always eluded the idea of providing an ETA or
roadmap for a libusb release, despite the question being asked by a long
stream of libusb users. IIRC, the only ETA we ever managed to obtain for
the 1.0.9 release, in the last quarter of 2011 what that it was due for
the end of that year. As one can plainly see, that deadline was missed
by 16 months (and would probably have been delayed for even longer were
it not for the libusbx fork). Not being able to tell users where a
project is headed or due for so long is clearly damaging. 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.
All in all, while controversial, I hope the above will help you consider
that there may be a bit more to libusbx than our people forking over
disagreement primarily related to Windows code, and that you may want to
have a closer look at what each project does, and how progress occurs.
Also, more relevant to the matter at hand, I'll just conclude by stating
that whether the effort to address Hans' issue is conducted in libusbx
or libusb, it shouldn't matter too much for the time being. However,
with libusbx subscribing to a Release Early, Release Often process (yet
another reason for oure fork), it is most likely that such an
enhancement will be first featured in a libusbx release.
Regards,
/Pete
[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
--
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
