[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it time to drop ChangeLogs?

From: Paul Eggert
Subject: Re: Is it time to drop ChangeLogs?
Date: Wed, 9 Mar 2016 10:24:33 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/09/2016 08:41 AM, Eli Zaretskii wrote:
From: John Wiegley <address@hidden>
... we have only a few needs. If I've understood
incorrectly, please let me know, as this thread has wandered in a few places.

  1. We need a way to ensure quality commit messages from contributors.

This boils down to applying social pressure, one way or another, regardless of the technical details about how ChangeLog entries are recorded.

  2. We'd like to be able to correct commit messages after the fact.
  3. We need a convenient way to both create and access this information.
  4. We want to publish the history of these commit messages in the tarball.

The ChangeLog file and its format are one implementation of these needs that
has worked over the years. Are you saying that if we move to something else,
and it fulfills these criteria, you'd be just as happy with it?

However, putting on my system engineer hat, let me make sure the list
of requirements covers all the aspects:

  5. The "history of commit messages" produced in 4 above should
     resemble a ChangeLog file (ideally, it should use the same
  6. The solution should allow manual generation of the "history" file
     mentioned in 4, on demand, in reasonably short time, even if the
     repo clone does not include a built Emacs.  (It is okay to use the
     installed Emacs binary, if necessary.)
  7. The solution should support Git workflows we allow: merging
     between branches, rebasing local changes on upstream,
     cherry-picking from another branch, reverting a commit, tagging a
     commit, and amending an unpushed commit.  "Support" here means
     that the solution should not impose limitations on these
     workflows, and the steps for updating whatever databases the
     solution will use should not require additional manual work as
     result of using these workflows.

The coreutils-like approach that I recently proposed should satisfy requirements (2) through (7). See:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]