Re: [PATCH] maint: add a rule to use gnulib's update-copyright

[Stefano Lattarini]

On 02/12/2012 06:57 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
> ...
>>> However, if you know of such test failures, it'd be nice to mark
>>> them as XFAIL as soon as you can -- even if just for a few days --
>>> to avoid wasted effort.
>>>
>> But by doing so we would risk to let such failures "slips through the
>> cracks"...  Still, having the affected tests printing a proper message
>> "I'm temporary failing due to commit ..." might help saving wasted
>> work.  I'll try to be more careful next time.  Sorry for the confusion
>> and sloppiness.
> 
> I don't want to slow you down, but if you were to simply add e.g.
> 
>   XFAIL_TESTS += name-of-temporarily-broken-test # FIXME: just temporary
> 
> there would be little risk of forgetting about it.
> If you think that's too risky, I volunteer to write a
> crontab-run script that will mail to the list whenever
> such a line remains for more than a week in maint or master.
>
Or here is a simpler (even if a bit less safe) approach: we could add to
'tests/Makefile.am' a new 'KFAIL_TESTS' ("KFAIL" as in *K*nonwn *FAIL*ure)
variable that gets added to XFAIL_TESTS:

  XFAIL_TESTS += $(KFAIL_TESTS)

and then update the 'git-tag-release' and 'git-tag-release' recipes to punt
if such a variables holds a non-empty value (so that we won't risk to create
a release with "known failures").  Then, if we still think that would be
valuable, we could add a crontab-run script on the top of that.

If you want to write such a patch (with proper rationales and updates to
'tests/README'), I'd be really grateful.  Otherwise I can do it in the
next days.

> ...
>>> with these envvar settings:
>>>
>>> update-copyright-env = \
>>>   UPDATE_COPYRIGHT_FORCE=1 \
>>>   UPDATE_COPYRIGHT_USE_INTERVALS=2 \
>>>
>> Why the "2" here?  The documentation in update-copyright reads:
>>
>>   If UPDATE_COPYRIGHT_USE_INTERVALS=1, every series of consecutive
> 
> That's only the first part of its documentation.
>
Oops, I was looking at an out-of-date local clone of Gnulib!  You are
perfectly right, sorry for the confusion.

> Just below that, it says this:
> 
>     #   If UPDATE_COPYRIGHT_USE_INTERVALS=2, convert a sequence with gaps
>     #   to the minimal containing range.  For example, convert
>     #   2000, 2004-2007, 2009 to 2000-2009.
> 
>> So we should just export UPDATE_COPYRIGHT_USE_INTERVALS to "1",
>> right?
> 
> No.  As you see, we both want =2  ;-)
>
Right :-)

>> But then, a more serious issue: are we truly and legally allowed to transform
>> a copyright notice like:
>>
>>   Copyright (C) 1998, 2002, 2010, 2011 Free Software Foundation, Inc.
>>
>> into this:
>>
>>   Copyright (C) 1998-2012 Free Software Foundation, Inc.
>>
>> without problems?  (I hope so, because I'd love the gain in compactness and
>> consistency).
> 
> Yes, per this (the commit log for the gnulib change):
> 
>     update-copyright: accept new option: UPDATE_COPYRIGHT_USE_INTERVALS=2
> 
>     * build-aux/update-copyright: When UPDATE_COPYRIGHT_USE_INTERVALS=2,
>     convert a sequence with gaps to the minimal containing range.
>     For example, convert 2000, 2004-2007, 2009 to 2000-2009.
>     * tests/test-update-copyright.sh: Test for this.
>     The FSF confirmed it is ok to do this, assuming there is at
>     least one significant change per year in the affected range:
>     http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/29554/focus=29860
>
Good!

>>>   UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79
>>>
>> I'd rather keep all the lines shorter than 76 chars if possible (this leaves
>> room for leading line numbers in a vim buffer, even for terminals with only
>> 80 chars per line).  Maybe leaving the default of 72 here would be even
>> better.  And BTW, if we go on with collapsing the ranges of copyright years,
>> all of this becomes moot, because then all the lines containing the copyright
>> years will simply be 54 characters long, no?
> 
> Good point.
> We can indeed remove the UPDATE_COPYRIGHT_MAX_LINE_LENGTH setting.
>
>>> Here's the first patch:
>>> (I don't particularly like to copy update-copyright from gnulib and
>>> VC it here in automake, but that's the current method.  Addressing that,
>>> if desired, would be a separate issue. )
>>>
>> Agreed.  What would you propose to address that?  (I'm assuming you'll agree
>> with me that having gnulib as an automake git submodule would be a *gross*
>> overkill).
> 
> Perhaps (some day) a submodule with the bits from gnulib's build-aux/ and
> top/ directories.
>
That would be good, yes.

> But that might mean moving them from gnulib proper to
> a submodule of gnulib.  I don't want to go there right now ;-)
>
Agreed.  And in fact I think that the present situation, while suboptimal, is
still perfectly acceptable.

>>> From fd93630e5c6aa9a9775ae945787b9903bab2f6c6 Mon Sep 17 00:00:00 2001
>>> From: Jim Meyering <address@hidden>
>>> Date: Sun, 12 Feb 2012 16:57:42 +0100
>>> Subject: [PATCH] maint: add a rule to use gnulib's update-copyright
>>>
>> I assume this patch is for the 'maint' branch, right?
> 
> Now it is.  I've amended with this:
> 
> diff --git a/Makefile.am b/Makefile.am
> index 6a6631f..496675e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -405,8 +405,7 @@ release-stats: ps
> 
>  update_copyright_env = \
>    UPDATE_COPYRIGHT_FORCE=1 \
> -  UPDATE_COPYRIGHT_USE_INTERVALS=2 \
> -  UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79
> +  UPDATE_COPYRIGHT_USE_INTERVALS=2
> 
>  .PHONY: update-copyright
>  update-copyright:
> 
ACK, and thanks.

Stefano