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 ------------------------------------------------------------------------------ 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
