This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update copyright dates not handled by scripts/update-copyrights [committed]


Joseph, the scheme you propose is close to what is used for GNU Emacs: everything is in a top-level ChangeLog, commit messages are in ChangeLog format, a script autogenerates the ChangeLog file, and the autogenerated ChangeLog file is committed just before release (and just before corrections are made).

Unfortunately there's a problem with this approach: it's a pain to merge. This is because different branches can have different committed ChangeLog files, which are mostly autogenerated but contain some hand edits. The autogenerated parts of these files are not necessarily in the same order even for the parts that are in common (because that's how 'git log' works). We have not solved this problem in Emacs, so in practice one branch (the release branch) has a decent ChangeLog file, the other branches are a mess, and after a release a massive ChangeLog cleanup is needed to the next branch (a cleanup that never gets done right).

I see several ways out of this problem:

1. Adopt the approach used in GNU coreutils etc., which have on-the-side lists of edits to ChangeLog entries. You've rejected this, and perhaps rightly so, as being too much of a pain to maintain.

2. Use a procedure based on "git notes" (or some other Git-based metadata) to store edits to commit messages. This would also be a pain to maintain, most likely, though perhaps less than (1).

3. Write a tool for merging mostly-autogenerated but partly hand-edited ChangeLogs. Unfortunately the only way to debug this would be to use it for a while and in the meantime ChangeLogs will likely be in a mess. No one has gotten up the energy to do this for Emacs.

4. Never fix ChangeLog entries. Only auto-generate them. If they're wrong, they're wrong: history records mistakes as well as successes.

5. Do not bother to auto-generate ChangeLog files. People interested in history can look at the Git history.

6. Like (5), but also delete existing ChangeLog files. As I understand it, this is what Mike Frysinger proposes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]