I've pushed rGdee244b48060 in the branch T3172 as a proposed fix for this.

The GPL requires us to keep and distribute ChangeLogs. Thus we can't remove them from the source tree.

I'm not sure i understand. Current changelogs don't go into the source tree, and yet that's not a violation of the GPL, so clearly keeping changelogs in the source tree isn't a requirement in general.

What part of the GPL requires that we keep and distribute ChangeLogs? They can't be an "invariant section" (a la GFDL) because the GPL doesn't allow for invariant sections. Proper attribution is required of course, but that doesn't need to be done in changelogs in the source tree.

can you help me better understand the constraint you're concerned about?

Both GPL versions require:

a) The work must carry prominent notices stating that you modified
 it, and giving a relevant date.

Now, we are using parts from other projects and thus it is best to document changes on a per-file base. The changelog is also the base to figure out copyright holders. This is a standard GNU project requirement.

Since 2011 we are using GIT and don't use the ChangeLogs anymore. The ChangeLog-2011 files are used to create the part of the tarball distributed ChangeLog where we recorded changes only in the ChangeLog. The former SVN and CVS commit messages were either copies of ChangeLog entries or just garbage.

For the git version there is no need to keep an ChangeLog beause all changes are instantly available from git. But for the tarballs, we don't have git and thus we generate a ChangeLog from Git and ChangeLog-2011.

Of course ChangeLog-2011 does not need to go into the tarball. But is needs to be in the repo and I consult the old ChangeLogs quite often. For gnupg > 2.2 we will consider to strip down the distributed ChangeLog to the minumum required.

thanks for considering this for > 2.2.

doing "git rm" as proposed still leaves the 2011 changelogs in the repository, just not on the master branch.

when generating a changelog from the git repo, we can pull the 2011 changelogs from wherever they can be found historically (perhaps just a tag on the last git commit before the cleanup).

I understand that you consult them often, but i've found that they confuse people who are looking at the project for the first time with an eye toward trying to contribute (they confused me for a while until i understood that i could ignore them). If being inviting to new contributors is a goal, this change should be seen as a small step on that path.

I understand. What do you think of putting a few lines on top similar to

NB: Changes done before December 1st, 2011 are described in
per directory files named ChangeLog-2011. See doc/HACKING for
details.

Which we put at the end of the generated ChangeLog.

If you're putting a note at the top of ChangeLog-2011, it should probably mention where the *other* changelogs are, not just an explanation of what this file is doing here. And while this does explain to a user who has bothered to read it what's going on, it's still not particularly friendly.

Just having the files present in the tree when they are not expected to be used is the confusing thing. Among other things, it means that running spell checkers over the files will result in ongoing warnings (i'm assuming that the files shouldn't have their spelling corrected). It means that a "git grep" will find references in there, but not in any changelogs more recent than 2011. And it means that one of the first files people see when browsing the source tree is a file that looks like the project has been inactive for 6-ish years. A comment at the top will correct such a misimpression, but just reading that comment is already time that the person reading has now spent instead of learning the actual codebase or contributing in other ways.

A clean codebase is an inviting codebase. I've now spent too much time myself trying to explain why i think they're problematic, and that's time i could have spent trying to deal with other GnuPG issues, so i'll step away from this thread now lest the ChangeLogs become even more of a time drain. I think i've made myself clear why i think they ought to be cleaned up.

Sure. If will explain where to find newer entries.

FWIW, if you look into GCC you will see several ChangeLOG-YEAR files.

This decision suggests that the accessibility of the current source tree
for new contributors (who are more likely to find the static, archaic
changelogs distracting) is unimportant.

I'm troubled by this decision, especially given how difficult it is for
new contributors to come up to speed on the GnuPG codebase.

Werner, surely you can keep a copy of these static changelogs anywhere
you like for your daily review. Shouldn't making the codebase more
accessible be a priority?

I recognize that removing the outdated static changelogs on its own
doesn't make the codebase fully accessible to new users, but it's one
small step in that direction.

Does the GnuPG project want to encourage or discourage new contributors?

Frankly, I do not understand your problem. We do _not have_ and useful information in the commit logs before December 1 , 2011. You may find some ChangeLog entries in older commit logs but that is from a time when _I_ used a script to copy the ChangeLog entries into the _CVS_ commit logs. That was never done consistently. Thus by looking at the commit log you will get a wrong picture. This is why we need to keep the ChangeLog-2011 files which start right at the top with

NB: ChangeLog files are no longer manually maintained.  Starting
on December 1st, 2011 we put change information only in the GIT
commit log, and generate a top-level ChangeLog file from logs at
"make dist".  See doc/HACKING for details.

Back then I considered to merge all ChangeLog-2011 files into a a single ChangeLog file but that turned out to be too complicated. Commit 2336b09779d313c1594acf6df3bd8a8486e90458 from that Dec 1 notes that all ChangeLog have been renamed.

Let me repeat: I consider change history very important and ChangeLogs are easier to understand than hundreds of diff.