Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Jim Meyering]

Gary V. Vaughan wrote:

> Hi Jim,
>
> On 15 Nov 2011, at 19:02, Jim Meyering wrote:
>> Gary V. Vaughan wrote:
>>> On 15 Nov 2011, at 18:14, Jim Meyering wrote:
>>>> Gary V. Vaughan wrote:
>>>>> I think 'Copyright-paper-required: No' is still the best compromise here 
>>>>> for
>> ...
>>>> This is setting FSF policy,
>>>
>>> Well, the policy is already set very clearly...
>>>
>>> From http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
>>
>> That part is not in question.
>>
>> The syntax you are proposing would set policy for
>> GNU projects that use gitlog-to-changelog.
>
> Not at all. It would set a precedent for sure, and it enables other
> projects to track '(tiny change)' annotations in git logs in accordance
> with the maintainer guidelines - but does not by any means set anything
> in stone... many GNU projects don't even use git after all.
>
>>>> For example, I have a slight preference
>>>> for a semantically positive tag like "Copyright-paperwork-exempt:".
>>>
>>> That seems fine to me too.
>>>
>>> Rather than stalling, what's the next step to keep things in motion?
>>
>> Propose a patch to maintain.texi.
>
> I don't want to get into a debate over the merits of generated
> ChangeLogs with RMS, which I already know he doesn't like.

I don't recall any objection to generated ChangeLogs.
No one ever gave me negative feedback about what I do in coreutils
(since 2008), diffutils, grep, etc., and as such I wouldn't expect
any debate.  It's established practice.

> So never mind this second patch, I'll just keep it in the
> gl/build-aux/gitlog-to-changelog.diff of my projects.  Any other
> project that likes it can find a copy there, or in the bug-gnulib
> archives. (Although I still think that if you use gitlog-to-changelog
> to generate all your ChangeLogs without tracking and correctly
> generating the '(tiny change)' annotations somehow, then you're not
> respecting the maintainer guidelines on ChangeLog entries.)
>
> How about pushing the multi-author patch?

I will re-review/test it and reply tomorrow.

I can give a little feedback already: I do not want to
add a bourne-shell git commit-msg hook script to gnulib.
If I thought the one we're using in coreutils were ready,
I would have proposed to add something general based on it.

There are two issues:
- we need more experience with the idea and the framework.
  I suspect that very few people have used it so far.
- it is not ready for gnulib: I am rewriting it in Perl,
  which is more portable, and with git, guaranteed to be available.