Re: coreutils + maint.mk + public-submodule-commit

[Eric Blake]

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