emacs-devel
[Top][All Lists]
Advanced

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

Re: Should we restore manually maintained ChangeLogs


From: Eli Zaretskii
Subject: Re: Should we restore manually maintained ChangeLogs
Date: Wed, 09 Mar 2016 21:57:59 +0200

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Wed, 9 Mar 2016 11:26:19 -0800
> 
> 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.

No, it's a very far cry from historical research.

> >> 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.

No free lunch, but some lunches are cheaper than others.

> 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.

That cost is much lower than any of the alternatives proposed so far,
including the current arrangement with ChangeLog.2.  It worked for
years.

If someone has a better proposal, let's hear it.

> Regardless of the approach taken, there is also a cost to 
> sprucing up the historical record

Since this is regardless of the approach, it shouldn't affect the
decision in this matter.



reply via email to

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