|
From: | Paul Eggert |
Subject: | Re: Should we restore manually maintained ChangeLogs |
Date: | Wed, 9 Mar 2016 11:26:19 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 03/09/2016 11:14 AM, Eli Zaretskii wrote:
This community is about software development, not about historical research. When I'm looking up a commit, I want accurate information about it.
Like it or not, that is a form of historical research. One cannot escape the basic principles of history, and in particular one cannot insist that the historical record must be error-free.
There is a reasonable question about how much of our development effort should be devoted to sprucing up ChangeLogs after they're committed. I think this should be low priority, whereas as I understand it you would prefer that we boost its priority. Neither side is advocating untrustworthy ChangeLogs, or perfect ChangeLogs for that matter; it's mainly a question of where to allocate our scarce development resources.I'm arguing that we shouldn't _need_ to allocate resources to it.
There is no free lunch here. There is a real cost to the old-fashioned approach of keeping commit messages as files in the repository. This cost is borne by every contributor, and the hassles of dealing with it was a primary motivation for Emacs (and other projects) moving away from that approach. Regardless of the approach taken, there is also a cost to sprucing up the historical record, a cost borne by the developers who do the sprucing-up. This sort of approach does work unless we devote real resources to it.
[Prev in Thread] | Current Thread | [Next in Thread] |