[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is it time to drop ChangeLogs?
From: |
Eli Zaretskii |
Subject: |
Re: Is it time to drop ChangeLogs? |
Date: |
Wed, 09 Mar 2016 18:41:27 +0200 |
> From: John Wiegley <address@hidden>
> Date: Tue, 08 Mar 2016 22:41:49 -0800
> Cc: address@hidden, Ingo Lohmar <address@hidden>, address@hidden
>
> > Find a better and more reliable way of dealing with the problems described
> > here, and I'll be the first to agree not to reintroduce ChangeLogs.
>
> As far as I understand so far, 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.
> 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?
Yes.
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
format).
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.
(I'm not saying these additions are something non-obvious, I just
want to make sure we have everything covered.)
- Re: Is it time to drop ChangeLogs?, (continued)
- Re: Is it time to drop ChangeLogs?, Stefan Monnier, 2016/03/12
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Dmitry Gutov, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Stefan Monnier, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Yuri Khan, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Yuri Khan, 2016/03/13
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/13
- Re: Is it time to drop ChangeLogs?, David Caldwell, 2016/03/13
- Re: Is it time to drop ChangeLogs?,
Eli Zaretskii <=
- Re: Is it time to drop ChangeLogs?, Paul Eggert, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Paul Eggert, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Ingo Lohmar, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Ingo Lohmar, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/03/09
- Re: Is it time to drop ChangeLogs?, Stefan Monnier, 2016/03/07
- Re: Is it time to drop ChangeLogs?, Nikolaus Rath, 2016/03/08