From: Pete B. <pb...@gm...> - 2010-10-09 23:45:04
|
On 2010.10.09 22:04, Peter Stuge wrote: > This attitude toward commits can create problems both for yourself > and for others who may be interested in engaging in the code. While, on the other hand, it does allow for providing results in a timely manner. Gotta know where your priorities are. Release Early, Release Often. Also, remember that we got was a monolithic patch from Nokia (no insight into their commit breakdown), and you should actually be thankful that I spared you [1]. > I haven't looked at the commits at all so they may be fine, but your > comments sound a little ominous. Only for people with an unnatural worship of git. People who see git for what it is, and understand that the benefits of splitting commits ad nauseam, just to get spared (or spare others) the very remote possibility of 5 minutes extra work, will never outweigh the benefits of releasing software in a timely manner, won't get offended by such a comment. But feel free to explain the worst case scenario of going into an official release (or a dev branch) with a single commit for hotplug. What exactly is there to be gained in splitting that feature? And how would you see it split then? How much additional effort would that take? > I think it's important to make good commits based on libusb.git, so > that you have as few differences as possible; that allows the code > to more easily be rebased. It's especially useful for branches that > live for a fairly long time before they are applied to libusb.git. Gotta wonder why branches have to live for so long then... Maybe that's where the actual problem lies. I already explained why branching off libusb.git didn't make sense for hp. >> - Branched of libusb-pbatard rather than official, due to the >> new-enum dependency on Windows > > I'm very curious about a new-enum patch for libusb.git. Not sure how I'm supposed to interpret this. I can provide a new-enum patch for libusb.git tomorrow if you want one. Basically it's everything from pbr307 -> pbh310 in [2]. I'm still trying not to clog the patch processing pipe for official, as there are still plenty that are unapplied in there (including fixes for bugs introduced by Daniel, like "-Wl," for --add-stdcall-alias and "libusb_1_0_la_LDFLAGS = $(AM_LDFLAGS) -version-info ..." in libusb/Makefile.am), but if you want more, I'm always ready to provide more. > As I pointed out in the attach/detach thread I do think libusb > touches on what libwdi offers, and both hotplug and attach/detach > could benefit from depending on libwdi. Have you read my post in the other thread? I have the feeling that you haven't, since you haven't replied to any of the concerns I raised there. Also hotplug off libwdi alone makes very little sense, as it'll make it harder to link to a libusb device. It only makes sense to do a libwdi (well Zadig really) kind of hotplug for driverless, as it's a very blind kind of hotplug. Finally, please clarify if you're implying that libwdi should also implement Linux attach/detach, and if you think that dealing with OS driver specifics should be provided by a separate library on Windows but not on Linux. Regards, /Pete [1] http://pete-tech.blogspot.com/2010/09/state-of-hotplug.html [2] http://git.libusb.org/?p=libusb-pbatard.git;a=shortlog;h=refs/heads/hp |