ChangeLog entry complexity

[Joseph S. Myers]

On Wed, 27 Mar 2013, David Miller wrote:

> I'm sure a GIT wizard would be more than happy to teach you how to
> data mine in exactly the way you want, but that's not what this
> discussion is about.

If something requires a git wizard instead of "grep", I think that 
illustrates a major deficiency in git compared to ChangeLog files.

The *greatest* deficiency I see in git however is the culture it attracts 
of people insisting some particular way of doing things with git is the 
One True Way and other approaches that work fine for people or things they 
find useful have no value.

Tarballs exist.  Version control systems other than git exist.  People 
import software from one place to another, even if version control systems 
other than git don't provide built-in equivalents of CVS vendor branches 
(which were a very useful CVS feature).  People providing source code for 
copyleft software on a device probably more often provide tarballs than 
version-control repositories (in which case if they modified the code they 
also need to provide some form of change log to meet requirements such as 
"The work must carry prominent notices stating that you modified it, and 
giving a relevant date." in GPLv3), and if they provide version-control 
repositories they quite likely don't include upstream history.

And it's useful to have history information present in such contexts.  
Denying the present utility of such information will just serve to 
illustrate my second paragraph above.  Maybe in future it will become 
universal for software source code to be distributed in history-carrying 
form, but it's very far from universal at present.

If you want to change practices for how descriptions of changes are 
created and carried around in glibc, seek common ground rather than 
denying the utility of things other people say they find useful.  Presume 
good faith when people say they find particular information useful and 
that they find it useful for it to be present in a particular context.  
glibc development works by consensus, so you need to seek consensus to 
obtain change.  You are more likely to get consensus on a closer 
correspondence of ChangeLogs and git log entries (potentially allowing 
some form of automatic generation), on including "why" information in both 
places, or on avoiding per-function or per-file information in certain 
cases of global changes, than on the lack of utility of things people say 
they find useful.

If you want history-carrying form of code to be universal, either glibc 
release tarballs need to include the git history (at least for ancestors 
of the version distributed, if not for other branches as well) or glibc 
needs to stop making release tarballs.  Likewise for GNU/Linux 
distributors' source packages of glibc, etc., and for other software as 
well - I don't object to such a goal, but I think removing ChangeLog files 
would be something ten years down the line if you have universal 
history-carrying code by then at least for glibc, something to do last, 
not first.

-- 
Joseph S. Myers
joseph@codesourcery.com