On 07/31/2016 11:50 PM, Manuel López-Ibáñez wrote: > Oh well, Ayush does not have access to different hosts, thus I > guess it is better that he focuses his limited time on functions that > he can test. There are plenty of functions that are both in gnulib and > libiberty but not in glibc. >
My experience on the gdb side is that these kinds of patches tend to move much faster if there's confidence they got wide host testing. I'm not a gcc maintainer, but I'd suggest: - Put the patches on a public branch (e.g., a personal branch in the gcc git mirror), and point at the branch in patch submissions. A branch is easier for the occasional passerby testing than downloading a patch and then curse a bit while trying to to figure out the base revision the patch was generated against, because it no longer applies cleanly on current trunk. - Explicitly call for testing help, pointing at the branch. This makes it possible for a global maintainer to reasonable call a timeout. As in, "as we've called for testing X ago, and clearly nobody cares, let's go ahead, and fix any fall out afterwards.") - Get access to the gcc compile farm and go the extra mile of testing the patches on a couple non-GNU/Linux hosts. For example, there are AIX and NetBSD boxes there. I sometimes do this on the gdb side, and it helps much with moving things along. - Still on the extra mile theme, install cross compilers, and cross build gcc for those. For example, Fedora has a mingw-w64 toolchain in the main repo, which makes it's easy to at least cross build for Windows. Thanks, Pedro Alves
