This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: David Miller <davem at davemloft dot net>, 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: Thu, 28 Mar 2013 10:00:09 +0530
- 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> <Pine dot LNX dot 4 dot 64 dot 1303271701550 dot 23096 at digraph dot polyomino dot org dot uk>
On Wed, Mar 27, 2013 at 05:28:34PM +0000, Joseph S. Myers wrote:
> 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.
I don't see how that makes a difference. Even if those tarballs have
a ChangeLog file, it's rarely ever maintained. I know that for Fedora
and downstream distributions (or for that matter Debian and
downstream) don't maintain the ChangeLog file for their backported
patches. They have their own changelog section in either glibc.spec
or debian/changelog that describes the backported change. Also, those
changelog entries are nothing like the GNU ChangeLog entries. They're
typically just one-liners.
So whichever way you're looking at it, you always look at the upstream
baseline and the additional patches separately. The only difference
removing a ChangeLog would have is that instead of reading into the
ChangeLog file to see what upstream changes happened, one checks out
the tag for that release in the upstream repository and plays with
git-log to see what changed and how and why.
Siddhesh