Pete Batard wrote:
>> >>> 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.
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. So I'm a
little more convinced now that I agreed with Peter. So yeah, CR doesn't belong
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.
That was one of the times, if not the first, that I stopped following what you
were doing -- it was that bad. So this is actually an example where Peter was
right. 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.
>> >>> 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?
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.
>> >>> 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,
...which, as you know, I read...
>> 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.
Well then don't give me the "maybe he tricked you crap". If you pointed it
out, that's not possible.
>> 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?
A problem...
>> 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?
Objectivity: it should've been reviewed, but, barring that, it's released, so
the easiest workaround is to make the structure a superset. Preference: you
already know I prefer to have that information present when it's available, so
I assume that question is rhetorical.
>> 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?
It's not optimal, but, given the situation with releases, this is the best
available option.
>> - 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.
Agreed. And that would've been fine.
>> - 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.
>> - 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?
>> 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.
>> Until you ask Peter to remove his extra version field,
Like it or not, that's not possible. It's been released. 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.
>> argue here about my behaviour
Actually, your stated intent, not your behavior. You haven't yet followed
through, thankfully.
>> >>> > 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.
I assumed that's what you meant when you said certain compilers had issues with
it, so YES, you should be aware of it. What other issue did you have in mind?
>> > 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).
>> > 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?
>> 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. We keep the
function names in and we keep the git describe in, even though neither always
works.
>> 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?
>> I have both Tgit and msys-git installed. What do you use?
msysgit only (well, rigged to the freeware (but not "free") SourceGear
diffmerge utility, my new favorite graphical diff/merge tool for the last year
or so).
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
