On 2013.06.27 16:15, Hans de Goede wrote: > Thanks, I've pushed the 1st patch,
Dammit Hans, can we please avoid [r|p]ushing _new_ core features when we're smack down the middle of an RC? Or at least, if you deem we really must have them, can you wait at least 24 hours before committing, so that they have a chance to be reviewed and/or tested on platforms that are known to be capricious (looking at you cygwin!)? While I appreciate Toby's effort, and I don't have any objections to _proposals_ being submitted whenever, even during an RC, I don't think _integrating_ this patch is something that should have been taking place during the RC. In most other projects I know, RC is really a freeze-off time during which only critical or trivial patches get integrated. To me, this patch doesn't qualify as one of those. Besides, you should be well aware that, with the number of platforms we have actually have to test for libusbx, there's too much of a risk that even a seemingly innocuous new patch will end up breaking one of the platforms that was greenlighted when we went to RC. It's not a question of if, it's a question of when. Or, in this case, it's not even a question of when. It's "Congratulations, this last commit just broke our 1.0.16 release on cygwin": ------------------------------------------------------------------------- $ make -j2 make all-recursive make[1]: Entering directory `/d/libusbx' Making all in libusb make[2]: Entering directory `/d/libusbx/libusb' CC libusb_1_0_la-core.lo CC libusb_1_0_la-descriptor.lo core.c: In function 'usbi_log_v': core.c:2109:3: error: implicit declaration of function '_snprintf' core.c:2124:2: error: implicit declaration of function '_vsnprintf' Makefile:452: recipe for target `libusb_1_0_la-core.lo' failed make[2]: *** [libusb_1_0_la-core.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/d/libusbx/libusb' Makefile:404: recipe for target `all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/d/libusbx' Makefile:312: recipe for target `all' failed make: *** [all] Error 2 ------------------------------------------------------------------------- At this stage, I'm almost tempted to just say "You break it, you fix it", but I'll see what I can do to sort things out. That is, unless Toby has more time than I do, and a cygwin platform he can test with. From what I can see, at least on my cygwin platform, __GCC__ is not defined (go figure - I don't remember changing anything from the defaults, so I expect other cygwins to be the same), hence the issue. Also, we had the exact same #ifdef test that was added by this patch 10 lines above (which I now have to wonder may also not produce the results we wanted for for cygwin), so we probably should have factorized the new code there. Now, due to the number of new commits that have been applied since we declared RC, I would *strongly* suggest that we announce a new RC after this is fixed, and delay the release accordingly (one week after the announcement of RC2 is what I would see as a minimum). The rule should be that, if an RC breaks one platform, then a new RC should be declared after this is fixed. This is to avoid getting into a scenario where I decide that I don't have time to retest all the Windows platforms on a near daily basis, and we get an unpleasant surprise such as the one above post release. > For the 2nd patch lets wait for Pete's comments. That, and the cygwin fix, will depend on how far behind I get on what I was planning to get done for Rufus, which is what I really want to spend time on right now. Regards, /Pete ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
