Kustaa Nyholm wrote: >> Ah, so Peter's 'solution' (as I've said I've been tool lazy to look >> at the code) to some perceived problem requires that the build environment >> invokes git ?!
No, it requires we either choose to not invoke git and make it blank, or that we TRY to invoke git and fail gracefully if it doesn't work. There's nothing broken about that. Whether or not it's useful is another question that I am not trying to address right now. 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? In regards to the second one, I certainly do remember specific instances where I disagreed with final decisions (most notably certain logging-related issues including toggling), but I don't remember anything about feelings. >> Remember his stance on RERO This would be moot if he weren't slow... >> 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. Didn't you have to revert this? >> 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. >> Remember the many times he refused to answer a direct critical question >> about project management? Could be that, or could be busy. >> 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? >> 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. >> > Each has its disadvantages. The latter is far more characteristic >> > of the cynical situation you outline, however. >> >> Yes, I want you to take a side with libusb because I think you should be >> smart enough to realize that trying to work with the current libusb is a >> waste of your time. If you still don't or won't, don't act surprised if >> I'm not going to help you any. 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. 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. >> >>> 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. 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. >> > 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. Debugging output will contain function names for people running on certain environments, but not others. How do you not see the parallel? 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. >> >>> 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. >> 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. 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? So it won't work for some people -- this is your point. It has to fail gracefully. Please forget about this registry idea of yours; I don't know where that idea came from, but it's probably fragile. Regards, Michael ------------------------------------------------------------------------------ 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
