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:03:10 -0400 (EDT)
- 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>
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Wed, 27 Mar 2013 16:55:57 +0000
> I think having such fully-defined conventions that allow automatic
> ChangeLog generation would be reasonable
Many of us are not advocating for that.
I don't think it's reasonable to ship a ChangeLog, in any form, at
all.
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 you make a tarball for a release, it's made using a signed tag,
so the GIT context in which to do commit data minining is unambiguous.