From: Peter S. <pe...@st...> - 2011-02-24 11:18:12
|
Pete Batard wrote: > >> the K branch. > > > > ..which should again be based on libusb.git or .. > > Right. So that: > > 1. it's a major PITA to do anything since both mainline and -stuge are > missing important stuff, like, you know, the MSVC project files, or > toggable logging, which I need for any serious development. Would suggest to start by adding those in two separate commits before anything else in K. Need only do that work once, since each commit in K should apply easily also when the branch that K started from moves forward. > But sure, I should waste my time duplicating files over and over, No, but making the commits once and for all, that you would like to propose, exactly to not have to duplicate the work later. > 2. mainline .. my branch No problem - you would easily include the changes in your "collection" branch where you gather all important things. Again should go smoothly, without conflicts. > am I supposed to release another bunch of binaries for the K branch No, or at least I don't think that would be useful. The purpose of the K branch (any branch really) is to make it as easy as possible to add the code into libusb.git. > I am currently seeing my branch as compensating for what mainline > is unable to do. Therefore, that's what I'll keep using as my base. Diverging further from libusb.git increases the required duplicated effort. > Neither mainline or -stuge are ready for K. WinUSB is in there, so I wouldn't expect the K commit to be very different from how they would look on top of -pbatard master? > How's that reworked configure.ac in -stuge coming along by the way? It's mostly removed, but still needs some more looking at. Am having fun with patches for Darwin from Freenect right now. > From what I'm seeing, you seem to have plenty of time acking > patches for openOCD, but surprisingly very little for a project > where you are, in effect, the _only_ maintainer... It seems that some patches require less effort than others. //Peter |