Re: [bug-inetutils] [PATCH] Use socklen_t instead of size_t to fix warnings on 64 bit builds

[Alfred M. Szmidt]

   > The patch looks fine.  If you want, I can install it.

   BTW, when applying patches in git on behalf of someone else, it's
   useful to preserve the authorship of the patch by either using “git
   commit --author 'Foo Bar <address@hidden>'” when applying them manually,
   or with “git am” when getting them from a mail box (which
   additionally removes anything between [] from the Subject and also
   preserves the author date). This way both the committer and the
   actual author get recorded, and it makes it way more easier to
   track and analyze them using git commands, for example with “git
   log” --author or --committer, “git shortlog” to get a list of
   contributors, etc. One can always also see both with --format=full
   with commands like “git show” or “git log” and similar.

We use ChangeLog for tracking who the contributor is (for copyright
reasons), tracking who the commiter isn't that useful.  Many patches
do not follow our standards, so blindly commiting them is out of the
question.

   Also you'll find that if people are asked to provide the ChangeLog
   entry in the actual patch, you'll usually get conflicts, the other
   option, having them in the comments to be transferred later on to
   the actual file, imply having to amend the changes after commit, or
   use stuff like “git am -i”.

This is not that hard to fix before a commit, we had to do it for CVS
and it is no different now.  When sending patches, the ChangeLog entry
should simply not be part of the actual patch.  And in many cases we
need to fix the ChangeLog entries, since they are incorrectly
formated, or are missing information.  Take the simple example that
you are using one space after end-of-sentence periods, in the GNU
project we use two; so I'd need to fix that before commiting. :-)

   Still, for sanity's sake I'd recommend either autogenerating the
   ChangeLog at “make dist” time from the git log ouput, and having
   normal git one line summary (the one coming from the mail Subject),
   and optionally more paragraphs describing why the patch or more
   details like error output, etc, and then the normal ChangeLog
   formatted entries. Or a bit more revolutionary would be to prescind
   of the ChangeLog file, which IMO is a relic from the RCS/CVS times,
   tools which were unable to properly record authorship, do aotmic
   commits, and be able to analyze and check in a fast way all
   previous history.  Which seem to be the main reasons exposed in the
   GCS for a ChangeLog.

This will simply not happen, one cannot modify a commit log after the
fact, which would produce incorrect ChangeLog entries.

Thank you for your suggestion though, they are most welcome even if we
might not implement them.

PS. RCS did do atomic commits.