John Wiegley writes: > 2. At some future date, should the main contributors no longer rely on or > want a separate ChangeLog file, we should: > > - Remove ChangeLogs from version control. > - Require ChangeLog format entries in the commit message, as long as it > helps us and improves the quality of contributed commit messages. > - Employ some mechanism, such as git notes, to amend incorrect log > messages when generating metadata for the release tarball. Aren't we doing that middle item already? As I read the CONTRIBUTE file, the section on "commit messages" basically says to use ChangeLog style. Which is good. Since a ChangeLog entry is always suitable as a commit message (i.e., there is no good ChangeLog entry which wouldn't work fine as the commit message for the associated commit too), then there's no time like the present to start having a commit message convention we can all agree on. Since we've already agreed on ChangeLog-style entries for ChangeLogs, I think we would also agree on it for commit messages... and CONTRIBUTE suggests that we have already done so. This is orthogonal to whether we keep ChangeLog *files* in the tree, of course. It just settles that we have one unified convention for log messages, and that convention applies to both of the places where log messages can be stored: in commit messages, and in ChangeLog files. So the only remaining question is about where information should be stored (and, if there is duplication, whether that duplication should be maintained manually or automatically). The question of what the information looks like is, I hope, already settled. -Karl