On 2012.04.23 13:15, Michael Plante wrote: > Peter's recently been very accommodating about copying patches that he > probably doesn't want in libusb, and quickly. I don't know if you've > noticed that.
Yeah. Isn't it strange what people will do when they realize that, far from what they believed until then, a strong enough group of people is very opposed to their actions, and they *actually* have to do something about it. > It's a fair concern in the hypothetical, but who is trying to follow whom > right now, and who should we really be concerned about trying to break whose > code right now? I submit that, based on that long branding discussion, you > might actually be projecting your own behavior onto Peter. Peter has been > guilty of acting slowly If you think he's only been guilty of acting slowly, then how short your memory is... Remember his stance on RERO and his statement that it is possible to write code with no issues, and that 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? Remember the other bullshit dictatorial statements such as "I just don't want CR in the repo", when it pleased him to just ignore elements that went against his "ideal" vision and all technical justification had been exhausted? Have you taken a look at the commits from libusb.git lately, and how many of Peter's seem to have gone through without any form of review or invitation for comments... like the version one? How's that for being "very accommodating"? Remember the many times he refused to answer a direct critical question about project management? 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? 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. Sorry, but Peter has been guilty of far more damaging behaviour than acting slowly, most of which either directly or indirectly impacted libusb users. Because of that, a hasty 1.0.9 release isn't going to magically fix libusb. > while you have been trying to make things difficult > purely for the sake of being difficult on anyone who doesn't yet want to > commit. I want people to realize that, as a project maintainer, Peter is bad news, and, I'm not gonna mince my words there, that any project handled by him alone, when there exists an alternative, should be avoided like the plague. I'll be the first to agree that it's not a very nice thing to say, but, after 2 years of seeing his work, with ample evidence to back up my claims, the first of which being a project that didn't release for years, that's really all I can say. As such, I very much consider that anybody still trying to work with a project with only Peter at its helm, are deluding themselves. If it's their choice, I'm not going to prevent them to do so, but don't expect me to join. > 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. >>> 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. For more than 2 years, I tried as hard as I could to work with libusb to see if a compromise was reachable. That time is now over. > 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? Are you complaining about an MSCV6 limitation or something? Please produce smarter comparisons if you do. >>> 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 agree with you here. So a function that returns a boolean indicating > which branch of the fork you're on would be a great API addition if and only > if we can get Peter to agree to it (i.e., such a new API must be compatible > across the fork to make sense). Feel free to work with Peter and libusb on that. I think I've been explicitly clear about what I will and will not do. If you choose to still work with libusb, please don't expect everyone to follow you there. >>> My vote however would be to place a big "OBSOLETE - IF YOU USE THIS >>> FIELD, UPDATE YOUR APP FOR LIBUSBX VERSIONING" > > How about "may be deprecated, depending on WHETHER we figure out how to get > it working with msvc"? I am not convinced we won't. Except it's a duplicate to what we have. None of the functionality introduced by Peter is helpful because we already have it, and thus have no need for a duplicate. 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. But sure, let's add a pre-build step that crafts a program that pokes into the registry to find the location of any git variant (what if people are using cygwin's git + MSVC? - I think we had someone that did), so that we can then invoke it to fill the describe tag. Oh, and of course, what we do in Visual Studio (which we need to apply 3 times: 2010, 2008, MSVC6) will need to be duplicated in WDK. How's the above for me being technically convinced "we" actually won't? > I think Peter showed > awhile back how to do some tricks with cmd.exe that we still haven't run to > ground. And there are pre/post-build steps. It would be ugly, no doubt. Ugly is not a major problem. Adding complexity, points of failure and duplication is another matter altogether. > And we could document it to be always-blank, in the meantime, as Hans has > said recently elsewhere. Sorry but I don't think there will be any meantime. But, again, if you think you can prove me wrong, I'll be waiting for a proposal that demonstrates so. 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
