On 2012.06.19 08:28, Peter Stuge wrote: > Pete Batard wrote: >> the API is really only one part of it > > In a library the API is almost the only thing that matters.
Ergo, you are stating that the resources a project can muster, and users requests don't matter, as per the exact elements I was bringing up. Not a big surprise, but I'm glad you made that plain for everyone to see. > We've > long ago established that the libusb-1.0 API doesn't fit Windows and > that the Windows code has to jump through hoops because of that. Has nothing to do with the problem at hand. There's no technical impossibility of fulfilling the 1.0 API requirements here. Just a matter of doing it within a reasonable resource usage frame. >> balance API requirements with resources, as well as user requests... > > An implementation needs to deliver what the interface promises. ...within the resources a project can master. This is the problem we have, and that we've been having for years, but that you seemingly can't grasp at all. If the resources aren't there, you can have the most comprehensive and thought through API in the world, you're still only gonna get a partial implementation. And this is where implementing API features in the order where users will get the most benefit out of it matters. Let me illustrate this point further: As a maintainer, would I want the recent topology calls of libusbx to be implemented in the *BSD backend ASAP? Of course I would. Am I going to request that soemone stop what they're doing with regards to libusbx, and get them to go through that implementation so that we satisfy the API requirements for *BSD? Of course not: having a partial implementation of the API on *BSD for the time being takes second fiddle to pressing matters that will benefit a lot more users. The exact same thing holds for partial hotplug support in the Windows backend. > Don't worry, Windows code is not getting any special treatment. Do extended integration delays not count as special treatment? Or are you talking just now? In that case, maybe the Windows *code* isn't, but if we judge by how eager you are at tagging potential flaws in the Windows backend as bugs, when practically none of these latest "bugs" you pointed out were the result of unintended design, if actually deserving to be labelled as bugs, I can't help but wonder... Let me ask you this then: Had the platforms been reversed, and OS-X been the OS where the discrepancy arose, would the content of your e-mail have been similar in immediately pointing out a likely bug in the backend, as well as dwelling on the amount of use report we get for OS-X (or lack thereof, which would actually be accurate here, in comparison with Linux and Windows) and how this impacts the likelihood of Liam's report being meaningful? I seriously doubt that. But do I have evidence to back this up? Pretty much. I could point for instance to a case where, as per your usual stance, you highlighted a specific behaviour of the Windows backend as unacceptable (had to do with the backend returning an UNSUPPORTED error code on an API call), but when provided with evidence that Windows had simply followed what OS-X was doing in that respect, it magically ceased to be a contention point. Therefore, as long as I see repeated evidence that the Windows backend is receiving "special" treatment from you, don't act too surprised to see me (over)reacting to that. > If > there is talk about bugs in the Windows backend just now then it is > because they are being exposed just now. That seems likely, > considering that the first release is fairly recent, and users are > getting in touch. I dispute that. We have had 2 years of prior usage despite the lack of release, and none of these so called bugs you tried to point out lately were unintentional, if bugs at all. If one looks at the libusbx git log [1], checks the entries tagged Windows, considering the amount of "bugs" we're supposed to have raised with the Windows backend lately, one will probably be astonished at the apparent lack of bugfix commits. The last actual bug, that was reported from a Windows user, and that needed fixing was the "deadlock in backend when submitting transfers" from Toby (a hard to reproduce one). Before that there was the usbi_fd notification removal pointed out by Uri, but that was an easy to spot regression introduced by an earlier code cleanup. The longjpmp gcc 4.6 crash issue has little to do with something we could have fixed beforehand, but everything to do with gcc changing its default behaviour. And the other stuff is just items that we spotted ourselves when running Clang or something, and not user inbound. Then of course, there's that alleged serious bug with enumeration that you got a report of on IRC, for which we still don't have a formal report... For bugs that "are being exposed just now" in the Windows backend, we're really short of patch fixes in git. Doesn't mean we aren't going to get a serious bug uncovered by our users tomorrow, and of course you will try to point out that I have been refusing to address behaviours, that you qualify as bugs, but that were related to hotplug. Still, I can't help but think that actual data to support your statement is a bit light. >> I'm reacting to your trying to pass your obvious *opinion* > > I really can't help that you read something I do not write. I wish > you wouldn't, but you will of course continue to interpret me as you > choose. I very much tried to quote what you did write. >> How is "there can be many users who do not have the same issue and for >> which everything is working" compatible with your original "there have >> not been very many reports of libusb use on Windows at all"? > > You answer this yourself in the next sentence: Except, in that next sentence, I'm pretty much saying that that I don't see how it follows. >> let's say your statement was really about the impossibility of >> estimating Windows usage "at all", > > I'm glad that you understand what I mean. I'm confused as to why you > ask me to clarify something that you already understand though. Not at all. I don't understand how you can take the 2 previous statements to mean the above, and I especially don't understand at all how any of this was supposed to have any incidence on the validity of Liam's report, which is the context in which you tried to use this bullshit about Windows use reports. That is, unless you were somehow trying to paint the Windows backend in a negative light. >> download figures > > You can consider a download to be a report, but keep in mind that I don't. Then why on earth did you suddenly start comparing SF downloads with mailing list usage reports? >> why on earth did you drag your feet for 2 years > > I guess I can't do anything about this mad misconception. When you have been the sole project maintainer of libusb for about the same amount of time, when that project, under the different very busy maintainer, had little trouble releasing on semi-regular basis, and when no releases were to be had until a fork occurred, it doesn't exactly look like a mad misconception. As the person in charge, the head of the project always takes the blame. This holds true besides FLOSS. If you don't like that, then you should consider adding other people at the head, to share potential blame with you... > You know > how much time I've estimated to have spent on libusb, And you know that I indicated that I most likely spent a lot more than that myself, and how the amount one person allocates is quite irrelevant with regards to the tasks towards which that time is actually allocated. If any of us were to have spent all that time on beautifying the code, or developing an libusb backend for the BeOS/Haiku platform, would it matter in comparison to people who actually worked at producing a release? > and it's confusing that you would call that dragging one's feet. See above. Time is one thing. Using that time to actually produce release and satisfy users is another. A lot of the time you invested or wanted to see invested was on matters that didn't seem to be directly beneficial for our users but when a forked release occurred, you somehow managed to immediately go to release, even bypassing RC. I think that leaves me with some ammunition to indeed qualify your actions towards the 1.0.9 release as feet dragging. You have now provided evidence that you could release on short notice. Yet, for almost 2 years, and despite repeated requests from all sides, you failed to produce one. > If you think that I'm a liar or incapable of estimating time then > that's another matter of course, and then that is what you have to > state. One again, if you don't invest that time in the right place, it hardly matters how good you are at estimating it. I don't think you're a liar. But I think you are clearly deluding yourself with regards to the project's priorities, or even where your priorities should stand as a maintainer (which is clearly highlighted with placing the API requirements as absolute - users and project resources be damned). I believe this has been, and continues to be, hugely detrimental for libusb users. >> before reluctantly providing a release > > Another misconception. I'm really thrilled with libusb-1.0.9! Well, this is actually the one place where I was primarily talking about time. Are you saying that you're thrilled with having released 1.0.9 the day after libusbx was, and with not going through an RC? Well, since you're so happy about releases, and I might as well try to conclude with something that may benefit our users after all, a quick question: when's 1.0.10 due? Or is it difficult to estimate the time required for the next release perhaps? Regards, /Pete [1] http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=shortlog ------------------------------------------------------------------------------ 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 libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
