Re: Is it time to drop ChangeLogs?

[Ingo Lohmar]

On Wed, Mar 09 2016 22:30 (+0200), Eli Zaretskii wrote:

>> > 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?
>
> Both.  (This is not the first time these issues are discussed.)
>
>> I would honestly appreciate it if you could point me to such a
>> discussion, as I am not aware of the arguments.
>
> In one word: manpower.  In 3 words: lack of manpower.

You have omitted the part where I said that I do not advocate a
mandatory review.  Several other schemes (some of them highly, perhaps
too highly, refined) have been proposed.

>
>> 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.
>
> It's not out of the question.  But we are just contemplating it.
> Before we could rely on it enough to make significant decisions like
> the one discussed here, we'd need stop contemplating, install the
> procedures to implement such a queuing system, run it for a while,
> perhaps augment it some, until it's reliable enough and brings
> consistently good results.  _Then_, and no earlier, we can base
> changes in development process on such a system.  We are not there
> yet.  Until we are, we need to find a workable solution with what we
> have now.

No disagreement here.  I am nowhere near an anti-Changelog zealot, BTW.
It's just that I think there were/are a lot of smoke-and-mirrors
arguments flying around.

In fact, I think that your above paragraph is a much better argument to
keep Changelogs around for the time being than any arguments that have
been made in this thread alluding to their importance in the development
process.

>
>> > 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.
>
> Unfortunately, they don't fit the bill.  See the rest of the thread
> for why.

This blanket statement is exactly as helpful as saying that they would
work perfectly fine.  We obviously disagree on this.