This is the mail archive of the
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: <normalperson at yhbt dot net>, <carlos at redhat dot com>, <pasky at ucw dot cz>, <roland at hack dot frob dot com>, <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>
- Date: Wed, 27 Mar 2013 17:28:34 +0000
- Subject: Re: ChangeLog entry complexity
- References: <Pine dot LNX dot 4 dot 64 dot 1303271427040 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 122444 dot 1693913000175389808 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1303271628190 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 125821 dot 1593463415239280090 dot davem at davemloft dot net>
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,
Joseph S. Myers