This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: David Miller <davem at davemloft dot net>
- To: joseph at codesourcery dot com
- 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 13:40:36 -0400 (EDT)
- Subject: Re: ChangeLog entry complexity
- References: <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> <Pine dot LNX dot 4 dot 64 dot 1303271733240 dot 23096 at digraph dot polyomino dot org dot uk>
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Wed, 27 Mar 2013 17:38:20 +0000
> 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
> glibc.
>
> 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.
This is what "git describe" is for, it tells you the closest matching
named tag for a change.
Sorry, still not convinced of a ChangeLog's utility.