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: <siddhesh dot poyarekar at gmail dot com>, <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:38:20 +0000
- Subject: Re: ChangeLog entry complexity
- References: <Pine dot LNX dot 4 dot 64 dot 1303271410180 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 122142 dot 866614393146675379 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1303271649050 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 130310 dot 1217698596264264862 dot davem at davemloft dot net>
On Wed, 27 Mar 2013, David Miller wrote:
> Are people working on the Linux kernel or other GIT projects without
> a ChangeLog really working at a disadvantage because the tarballs
> lack an automatically generated ChangeLog file?
When working out when a syscall was added to the Linux kernel on different
architectures (say) I generally find it easier to use the diffs between
release versions rather than the git history of individual changes.
Among other things, dates in git history reflect the date on which some
relevant commit was made in some git branch somewhere, and not when the
change actually made it to Linux's tree and so into kernel.org release
versions, which are what's relevant for --enable-kernel configuration in
So, yes, a file that showed immediately the ordering of a change in
mainline Linux with respect to previous and subsequent release tags
(rather than its relation to a more complicated history involving lots of
other trees, which is also useful in other ways) would have its uses.
Joseph S. Myers