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.
