On 2012.04.26 06:58, Michael Plante wrote: > I know the bug was the final thing. That's why I mentioned I thought there > were other reasons. Remember that I had originally tried (and privately > emailed you) about the fact that I couldn't replicate what you did.
Yes, and had no idea why that was the case, and completely ignored my justification on how this could never happen on mainline, by insisting, despite being able to provide any form of evidence, and against all test results (I did run quite a few tests, IIRC), that there was still a risk it could. That's why I started to ignore your pleas on that matter after a while, because they were turning into FUD. > So I'm a little more convinced now that I agreed with Peter. Indeed. Convinced, despite evidence of the contrary, which is what I used to reach my position. > So yeah, CR doesn't belong in the repo. Please back this up with better evidence than "I once saw something happen, which I CANNOT explain and that, if confirmed, is more than likely to be due to a git bug that needs to be addressed by the git developers or a purely environmental issue from my system". Until then, using this as a justification for CRs not belonging in a git repo (DESPITE plenty of people doing it without experiencing issues) is just FUD. Also, with regards to the topic we're discussing, Peter statement wasn't "Because I think there is a risk, I don't want CRs in the repo" but simply "I don't want to have to provide technical or logical justification for my position - I just don't want CRs in the repo" > I think what we didn't know until months later is the root cause, but it was > obvious there was a problem, which was something you wanted to ignore when I > pointed it out privately. ...and once again your memory is either short or selective, and you ignore the fact that what we tried to establish that what you did in your own personal repo could have no impact on mainline. I spent weeks trying to highlight that. > That was one of the times, if not the first, that I stopped following what > you were doing -- it was that bad. Yes, it was one of the times where you stopped acting rationally and dismissed evidence, to go instead with a gut feeling. > So this is actually an example where Peter was right. Not in the way he formulated it, he wasn't. Which was the point. He didn't try to back his position with any logical or technical point. > Times when I *temporarily* stop following you are really the sticking point > for large changes like your file rename propositions. Permanent is fine, and > continuous following is also fine. It's the breaks that are the problem. Then I'm curious why nobody else ever seems to have reported an issue with this, and why none of the many people who are introduced CRs in their repos at one stage or another seem to complain (happens all the time, in the same fashion as the libusb CR change I proposed - for instance a flaky autocrlf made that happen a lot on the repo I had with libcdio). Also, other people have been following my tree, and yet they haven't complained. As far as I know, you haven't been "following" as much as you've been reusing bits and pieces into your own self-maintained tree. > Well, that wasn't what *I* meant, but yes, an RC would've been much, much > better. I think we both know why he did it this way, though. We can both know why someone did something bad. Yet that doesn't excuse it. Or do you really want to place the blame of libusb not going through an RC squarely on libusbx? Sorry, but that's entirely due to what I am trying to prove here, which is that Peter is doing just does his own things, without any shred of consideration for users. > ...which, as you know, I read... >(...) > Well then don't give me the "maybe he tricked you crap". If you pointed it > out, that's not possible. Well, from the above, it seems that reading what I say doesn't meant that you actually understand what I say. > Objectivity: it should've been reviewed, but, barring that, it's released, > so the easiest workaround is to make the structure a superset. Interesting, since we released first. I could argue that the first project to release gets to do whatever they please. The easiest workaround, if you had been objective and complained to Peter straight away, would have been a revert in libusb. >>> - It is Peter alone who took the decision to deviate and break library >>> interchangeability... Yet there is no possibility of considering it >>> hostile? > > Taken in context with all other statements by the two of you, I see that as > an unlikely motive. Well, if you're saying that Peter could not have had any hostile intentions when doing his own thing with regards to versioning and ignoring what anybody else might have wanted, then it can only mean that Peter did a very poor job at being a maintainer. Either way, you're proving my point. >>> - Somehow, this whole issue is something you see as a pure libusbx problem. > > libusbx has a subset of the fields. This is a specific case. Are you saying > I've never tried to have Peter accept patches for libusb? How does that follow? I'm talking about this *specific* issue. How do you turn that into a general statement about getting patches accepted as a whole. Again, what I am saying is that, while your objections about libusbx not doing anything with regards to the extra version field are amazingly strong, you appear to have had no inkling to ever ask Peter to remove his extra version fields, which a few of us here find quite strange. >>> 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? > > Because you stated the intent to do so, and Peter stated the opposite, and I > am taking both of you at your words. Peter can state whatever he wants, but the *facts* are that, by choosing to do whatever he pleased for the version, and not asking anyone, as well as you not objecting to his version addon as soon as you saw, to ask for revert, despite the fact that you consider it a major issue, you both created a very hostile situation. So there's intent, and there's actual action. Guess which one carries more weight... >>> Until you ask Peter to remove his extra version field, > > Like it or not, that's not possible. It was if someone like you had *chosen* to be objective and complained to both libusb and libusbx. > It's been released. And it had been released with libusbx first. > At the very least, one distro picked it up within at least a couple days > (this past weekend was when I synced and noticed it was already there), if > not immediately. And that same distro can always revert if the libusb removal was enacted quickly and 1.0.10 was released as bugfix. But, yeah, that's "impossible", because Peter should be free to do whatever he pleases. Has there been an actual official release of a distro with libusb 1.0.9 yet? I'd suspect that, unlike what is the case for libusb, any major distro goes through at least a couple of weeks of RC, where it would give a chance to apply a bugfix release. >>> 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. > > I assumed that's what you meant when you said certain compilers had issues > with it, so YES, you should be aware of it. Are we still talking about the function names not appearing in usbi_dbg() for MSVC6? If so, NO, I wasn't aware of it when you pointed it out. And for the record, as long as it's confined to MSVC6 and it's a compiler limitation, I very much don't care about it. > What other issue did you have in mind? None. You were the one pointing out that I was supposed to be aware of something, that I wasn't, and that I therefore tried to figure out. >>>> 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? > > Exactly that environment -- it's an analogy. And if you split everything > apart like this, people are going to lose the context of the analogy (I get > slightly paranoid someone might think I'm complaining here about it -- as I > state below, I'm not). Then let's clarify: Your point is that missing the function names in usbi_dbg for MSVC6 is entirely equivalent to the describe field not being populated if git cannot be invoked. My point is that, unlike what is the case for the MSVC6 LIMITATION, we do have a solution that provides equivalent data to what the describe field may provide, and that isn't subject to any limitation, as it works for all platforms (since this data is populated upstream by the maintainers). Ergo the describe field is not only completely unnecessary to carry, but, even if we are to do that, unnecessarily limited unless we don't attempt to populate data for all platforms where it can be populated (eg. my platform where git could be invoked but does not exist in the path), as in this case case, any limitation is per our choice rather than per an external entity's choice. You may not see a difference here, but I very much do. >>>> 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. > > No, it's not important to me -- I thought it was important to you. If it's > not, then what is your problem with Peter's changes? See above. Unnecessary duplicate, aimed at people like you or Peter, who blatantly refuse to see the merits of an existing UNIVERSAL solution to go with their limited one. Basically, you and Peter just went: "The libusbx solution works just fine, but I don't like it. Let's implement a worse duplicate and penalize everybody else as a result, so that we can GET OUR WAY". Having to handle someone else's selfish actions is the problem I have. When people explicitly call for the libusb and libusbx APIs to be uniformized, you and Peter should realize that duplicating something that works, simply because you don't like it, is not the way to go. >>> 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." > > Then forget HID -- maybe that was a stupid comparison. The MSVC6 comparison > was the perfect analogy, and I'd suggest you look at it again. I did. And I see nothing "perfect" there, on the contrary. > We keep the function names in and we keep the git describe in, even though > neither always works. Except, unlike what is the case here, we don't already have a duplicate solution to provide a function name equivalent in usbi_dbg, and rather than the absence of funcnames being a choice that we make of not going as far as we could to provide them, it is an MSVC6 limitation that we can't work around. >>> 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. > > Ok, so it's not > > 1) a blank string > > 2) a problem with some environments working and others not > (which is actually what I thought you were worried about, > though you're now saying you're unaware of this) > > So where did you clarify your concern? 2) is enough to tell me that you either don't read or don't understand my previous statements. 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
