On 24 April 2012 13:46, Michael Plante <michael.pla...@gmail.com> wrote: > Pete Batard wrote: >>> getting early user feedback wasn't that important? >>> [...] >>> Remember his other statement of people like himself (i.e. alleged "good" >>> maintainers) simply being able to "feel" what was right or wrong in >>> terms of development? > > Not really, but maybe it was just phrased differently?
Not really. It was pretty much phrased like that. I'd have to dig up the post, which may require a long time, but the general idea as stated by Peter was that, past a certain stage, a "good" maintainer (or was it a "good" developer) was simply able to get the feel of a proper solution, and this argument was used in an "therefore you should acknowledge that I know better than you" kind of way... >>> Remember his stance on RERO > > This would be moot if he weren't slow... Except it went further than "RERO doesn't suit me because I'd prefer to have some time". Basically, Peter pretty much stated (or very strongly implied) that he thought that anybody who followed RERO was wrong, especially after following it with a statement indicating that the RERO approach was unnecessary as writing software without defect was achievable. This was part of his rebutal to an example I provided, where I indicated how early user involvement and testing would have been critical in avoiding a very simple yet damaging lack of coordination with regards to what a horizontal line was supposed to be interpreted during the course of development of software that handled interlaced video >>> bullshit dictatorial statements such as >>> "I just don't want CR in the repo", > > Maybe now I'm just confused, but I thought I actually agreed with him here, > partly because of some sort of bug in git, and possibly for other reasons. Of course, what you don't recall is that this statement was uttered BEFORE we had any indication that there was a bug. Your memory is short. > Didn't you have to revert this? Yeah, after we discovered it was a bug. The main point of contention was that none of us, myself included, believed that git could have that critical a bug, and even has we thought the behaviour we observed was normal, and where, if confirmed, the only logical course of action would have been to go with a workaround that included CRs, his position was to reject any idea of it wholesale, with no alternative then but to inconvenience Windows libusb users as a whole, for the sake of "preserving" the git repo from CRs. >>> without any form of review or >>> invitation for comments... like the version one? How's that for being >>> "very accommodating"? > > Hrm, that was sort of my point about him accommodating your changes, > although it is kind of annoying that he didn't split it from what you did > into two separate commits and post the second for review. I guess that's > what you mean? Yes. Very true. That's not what I mean. You made a general statement about Peter being more accomodating now, which, since you still seems to see as applying, I will easily refute even further (along with his previous statement that the libusb 1.0.9 release happened as he ahd planned) with the following two letters: R, C. What kind of a maintainer goes to release without an RC? Or should we consider that that the RC that happened months ago still applied for this release, even as plenty more game changing commits occurred? I don't care much about about Peter not being accommodating towards me, but going to release without and RC, and, as per the original statement I was trying to make, committing important patches without asking for anybody else's opinion is what I will use as evidence to disprove your idea that he is being more accommodating as a maintainer than before. >>> Remember the many times he refused to answer a direct critical question >>> about project management? > > Could be that, or could be busy. Again, your memory is either short or selective. Many people asked him over and over about adding new maintainers and/or a 1.0.9 ETA. These mails are very easy to find. Please take the time looking for Peter's answer to these very direct questions. Also you may want to check what he was doing in coreboot and openOCD at the same time, where he would often be seen answering trivial questions that the other maintainers there could have handled, in order to reply to these critical libusb matters. >>> Remember the many times, where, after being proved wrong, he kept >>> silence hoping (but maybe this trick worked on you?) nobody would pay >>> further attention to it? > > No, but maybe, if it was a trick, someone (someone = you, since you > obviously spotted it) should've pointed it out? I did, as I did his many other deficiencies as a maintainer. Sometimes you may want to consider that the lengthy mails I took the time to write were a genuine attempt to try to warn people out, especially as, if you expect people not to be willing to hear you out, as you do here, you can't exactly sum up a warning in a one liner. I think I spent the best part of the last two years trying to warn libusb-devel of what was likley to, and did indeed happen, with regards to Peter's actions and damage to our users. So please don't give me that "maybe you should have pointed it out" crap. I did. >>> Remember how we waited about 2 months on his promise to privately review >>> the second (or was it the third) Windows patchset, with nothing > happening? >>> etc. > > This is slowness, my original point. Nothing new here. Fair enough. Then how about I replace this one with another which has nothing to do with being slow: When asked why one of the first Windows patchset fell through, and why it didn't receive any comments, either positive or negative, which resulted in further delay to integration, Peter also indicated that he let it fall through because he "didn't think it was good enough, but didn't want to comment on it". How's that for non-damaging maintainer's behaviour? > I never said I was going to side with libusb. My only point is I don't > think Peter is trying to or will intentionally try to break anything purely > for the sake of breaking it, which is the scenario you laid out. I like to envision possible scenarios. Hope for the best, prepare for the worst. Also see below. > The > scenario you proposed forces people to go one way or the other, which is > your stated strategy right now, and apparently quite the opposite of > Peter's, so I found it quite odd you'd ascribe that PARTICULAR behavior to > Peter. Except you assign a problem to libusbx that is Peter and Peter's alone. Rather than be accomodating, as you say, and apply the patch as is, he made it incompatible by applying his own preferred yet disruptive approach, which of course conflicts, and now forces us to resolve a conflict. If you want to be consistent then, where are your calls to Peter to revert his addon, since the majority here seems to agree that it isn't helpful and is causing problems? It really makes as much sense to call him to revert as us adding the extra field. How comes you aren't as indignated by Peter's behaviour then? Or is it that his proposal is indeed the one you would prefer, so being objective on this matter need not apply? For the record we were there first with a versioning proposal, and Peter took the deliberate decision to go over it and force our hand. And yet, you're telling us that, libusbx having its hand forced is OK, whereas libusb having its hand forced (i.e Peter reverting his extra version field) apparently isn't something you're willing to consider? The facts are: - Until libusbx used extra versioning, libusb wasn't using extra versioning, and seemed to be fine not doing so. And nobody expected Peter to introduce his own versioning in an unconcerted manner (where people could have told him about the shortcomings), the day after libusbx went public. - We certainly didn't ask libusb to do anything with regards to extra versioning - Peter could have just ignored the patch, or keep the version struct as is and leave the nano unused, as libusb was doing it until then. - It is Peter alone who took the decision to deviate and break library interchangeability... Yet there is no possibility of considering it hostile? - Somehow, this whole issue is something you see as a pure libusbx problem. I can't help but wonder then, why, when in light of the above I try to anticipate Peter's further potential attempts (either voluntary or involuntary) to disrupt libusbx, you are taking objection, and worse, because I dare formulate that we may want to tconsider repeats of this very damaging act since we now have a precedent, I am suddenly to be assumed as the one willing to cause harm? Until you ask Peter to remove his extra version field, which will be equally good at solving the problem at hand, whatever you want to argue here about my behaviour is cannot be deemed as receivable because clearly, you are demonstrating that you aren't impartial to the situation. >>> >>> In its current implementation, as I explained, I very much see > Peter's >>> >>> versioning buggy as it unnecessarily breaks cross-platform, >>> > >>> > Did you file a bug? >>> >>> I consider libusb dead. > > I was being facetious. I don't consider it buggy. I do (for the versioning). I just said so and also repeatedly tried to explain why I considered it that way in this very thread. Are we going to get back to a repeat of: - I think this is black - No, you shouldn't say that. You can only say it's white. > You can argue about > usefulness or optimality or value-added or whatever, and you may or may not > have valid points, but I remain unconvinced that it's buggy. I made my statement, you made yours, and we also know which extra versioning you would prefer to be implemented, and therefore how your judgement can be biased (whereas, if you want to accuse me of a similar bias, please remember that I spent the best part of last month providing evidence, which everyone can refer to, on why my versioning proposal should be technically better). Nothing new to see here. >>> > If you just means it doesn't always produce an output, >>> > you could say the same about the fact that I don't get function names > in >>> > usbi_dbg. Should we get rid of function names for everybody? >>> >>> You'll have to be more precise about that one, because I don't see what >>> it's about? > > The version function will produce an extra string (a git-related string) for > people running on certain environments, but not others. Am I supposed to be aware of that issue? Sorry, but until you pointed out, either I once was and forgot it, or I have never been confronted to that issue for it to actually register. > Debugging output > will contain function names for people running on certain environments, but > not others. Care to be more specific about these "certain environments"? Oustide of the very obsolete expected MSVC6, what are the others? > How do you not see the parallel? Because you're assuming that I was aware of a problem that maybe is important to you, but that I actually wasn't aware of until you initially pointed it out, and only got confirmed now. > I am not complaining -- quite > the opposite. My point is that some environments will have features that > others will not, but the feature can still be kept. > > I think you've made this same argument (though I don't completely understand > it, as I never use it) about HID, to cite another example. As I guessed your issue was with MSVC6 not displaying function names I knew the HID comparison was coming, which is the precise reason I added the following to my statement: "Please produce smarter comparisons if you do." If an environment doesn't support standrad C features, such as VA_ARGS or __FUNC__ (or whatever the macro is called), it is a LIMITATION, and isn't our job to implement or work around it. It's the build environment's developers'. This is very different from HID inclusion. HID support is IMPLEMENTED in Windows, through a public API, therefore the choice and ability to use it is ours and ours alone. So, the difference is: in the first case, there's no reason for libusb(x) users not to understand why, with MSVC6 NOT supporting the feature, we may not spend too much time trying to compensate for it, whereas, in the other case, with Windows very much supporting the HID API, we'll have a much harder time making libusb(x) users swallow the idea that we don't want to bother with it, even more so as we DID implement it, it was working satisfactorily for most, and a single person (rather than actual technical limitations) decided on its removal... I can only state again: Please try to produce smarter comparisons if you want to prove a point. >>> >>> Any application that uses Peter's versioning will have >>> >>> issues when it comes to Microsoft compilers >>> > >>> > Have you tested this? >>> >>> If you ask the above, then I have to ask in return: Have you looked at >>> the commit? > > Yes. I think Microsoft compilers handle blank strings just fine, though I > haven't tried it. That's why I asked if you tested it, and I still haven't > gotten an answer. The question is not about handling blank string. If you think my concern has been about libusbx breaking on blank strings, I seriously am going to cut this conversation short, because you're using a false dichotomy as well as ignoring what I went great length clarifying. >>> Also, figuring out the git executable directory, if msys-git is used >>> will require poking in the registry. At least on my system (and I don't >>> remember doing anything special there) msys-git is not in the default >>> path. Likewise, WDK invocation of git yields nothing. > > Odd, I did nothing special and git runs just fine for me. Well, I certainly do hope it can work for some people. How about a library with a feature that works fine for some people but doesn't for others, and has nothing to do with system limitations? I guess as long as you don't belong to the group where it doesn't work, we should consider it functional, right? > And that was > unintentional, as I *never* intended to run it from plain cmd.exe. But I > also don't use tortoisegit. Maybe that's the difference? I have both Tgit and msys-git installed. What do you use? > So it won't work for some people -- this is your point. Indeed. > It has to fail gracefully. Which has nothing to do with my point. I very much expect a derivative of Peter's solution fianlized for MSVC to fail gracefully, but I haven't tested if it does (because I'd need to modify his patch). And now I am starting to wonder since WDK will return "command not found", which I guess is what will end up in the string. Still, I will assume it fails gracefully and won't go replacing the static string we will want to set for the cases where git invocation didn't work, as it doesn't matter much for the point I am trying to make. > Please forget about this registry idea of yours; I don't know where that > idea came from, but it's probably fragile. It comes from the fact that, on my machine, where I very much have a git that could be invoked from the commandline available, your anticipated solution will fail to use it. I would very much prefer it did, else it means that even people who could get the version data field populated won't, which makes the "solution" even worse. Regards, /Pete ------------------------------------------------------------------------------ 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
