On 04/09/2015 11:00 AM, Bernhard Voelker wrote: > On 04/09/2015 05:50 PM, Paul Eggert wrote: >> Andreas Grünbacher wrote: >> >>> This behavior is discouraging testing; I find that quite annoying. >> >> Me too. It's bitten me several times and I can never remember how to shut >> it >> off. Perhaps we should remove that test from 'make check' and have a >> further >> rule 'make checker' that is stronger than 'make check' and which does the >> additional gnulib check. (If we can think of 3 levels, they could be 'make >> check', 'make checker', and 'make checkest' :-). > > Actually, it is a release-time check, so IMO 'make dist' or 'make distcheck' > should fail in that case, rather than 'make check' during the development > phase, > shouldn't it?
No, it is not just a dist-time issue. The reason we added it is because more than once someone pushed a change to coreutils.git that referred to a local gnulib.git change they were testing, but had forgotten to push the corresponding gnulib.git change; breaking the repo for any other developer. Worse, if gnulib.git changes in the meantime before the error is detected, then the only way to unbreak the situation is to either do git reverts (bad) or merge commits (gnulib.git likes linear history, but if you search for merge commits, you can find where we've had to temporarily disable its hooks to allow a merge commit for solely this reason). Maybe 'make check' is the wrong time, and a 'git push' hook is the better place to be doing it. But we DO want to prevent pushing a patch upstream to the public repo that relies on a submodule commit that is not public, as anything else is not nice to clean up after. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
