[Top][All Lists]

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

Re: Is it time to drop ChangeLogs?

From: Ingo Lohmar
Subject: Re: Is it time to drop ChangeLogs?
Date: Wed, 09 Mar 2016 20:51:15 +0100
User-agent: Notmuch/0.20.2+113~g6332e6e (http://notmuchmail.org) Emacs/ (x86_64-pc-linux-gnu)

Hi Eli,

On Wed, Mar 09 2016 05:46 (+0200), Eli Zaretskii wrote:

> That's because some people don't seem to read the thread, and keep
> coming up with the same incorrect arguments time and again.

Ok, so now we have established that we both think the other is not
reading the read "correctly" :)

>> "git log" messages cannot technically be both immutable and
>> unreliable: At least there is some severely imprecise use of
>> language going on.
> You need to read the thread to understand what is being alluded to.
> "Unreliable" in the sense that its text includes mistakes and cannot
> be trusted.

I realized that this may seem like nitpicking and apologized in my other

> Emacs development doesn't work by requiring each commit be posted for
> review as prerequisite for committing, so what Oscar suggests is not
> possible.  (Please don't ask why, it was explained many times
> already.)

Do you mean in this thread or elsewhere?  I would honestly appreciate it
if you could point me to such a discussion, as I am not aware of the
arguments.  In fact, in this very thread, the previous Emacs maintainer
has contemplated an automatic queueing system, so it surprises me that
such a scheme should be totally out of the question.  (Note that I have
not advocated any specific means, like posting each patch for review.  I
realize there is a lot of work and little time, and I greatly appreciate
your constant work on Emacs.)

>> The whole argument for Changelogs comes down to a) being an established
>> band-aid to clean up spilt milk, or b) providing a fixed-form summary of
>> things that can be obtained using the VCS (provided the humans or tools
>> wirting the Changelog are as "reliable" as the VCS).
> 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.

Several solutions to both a) and b) were proposed in this thread.

reply via email to

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