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 <meyer...@redhat.com>
>>> 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
