Re: Is it time to drop ChangeLogs?

[Karl Fogel <kfogel@red-bean.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>Paul omitted an important part of what I said, which of course made
>the point I was trying to make incoherent.

I read the original message (it was https://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00405.html, right?).

>And you are just repeating his omission.  And then you claim that
>others cause confusion, whereas in fact you confuse yourself (and
>perhaps others) by reading selectively what I and others say.  How
>does this make any sense?

I'm not sure what omission you're referring to.  You've referred to it twice now, but not specified what it is, and re-reading your original post I am unable to figure it out.

For example, your original post wrote:

> Writing ChangeLog entries is just one small part of that.  It's no
> accident that people who don't want ChangeLog files more often than
> not don't want to write detailed commit log messages, either, and many
> times don't know how to write good documentation.  Do we want to
> dispense with these as well?  If we drop the ChangeLog files, there's
> no way we can explain why we ask for commit log messages in ChangeLog
> format, so the next logical step is to drop that as well, and we will
> then lose valuable information.  We already are firmly on that path.

How does dropping ChangeLog files cause us to not be able to ask for ChangeLog-style entries?

(Also, I'm not sure your assertion about what kinds of behaviors correlate is true, but that's a separate issue.)

You wrote of the importance of "ChangeLog files" to forensics, but having that information in git commit messages is exactly equivalent (I use it for forensics all the time, in lots of projects).  Maybe you meant something like preserving the *existing* ChangeLog files, even if we don't maintain them in the future, to make it easier to do forensics involving changes that happened before CONTRIBUTE started asking for ChangeLog-style entries in commit messages?  If so, that wasn't at all clear from your post.  That's an ambiguity of the word "drop", perhaps: dropping ChangeLog files could mean removing them from the tree altogether, or it could mean leaving them preserved in amber but not adding material to them anymore.

When I read your post, I concluded that you were not proposing the "preserve in amber" approach, partly because of this:

> So removing ChangeLog files will be a bad blow to our ability to
> easily and conveniently research the past, something that is extremely
> important in a project with such a rich history, where it's all too
> easy to reintroduce a bug if you don't look hard enough at the history
> of some code fragment.
> 
> People are saying it's an extra barrier to contributing. ...

If the "removing ChangeLog files" in the first part had just been about removing the existing ones (in a hypothetical universe in which we didn't plan to add material to them in the future), then the first sentence of the next paragraph, "People are saying it's an extra barrier to contributing.", would have been a non sequitur, because a ChangeLog file that one isn't obligated to add to is not much of a barrier to contributing.  Anyway, a few sentences later in that paragraph you wrote "Having to write ChangeLog entries is an insignificant addition to the body of knowledge a contributor needs to master, there's no way around that." ... so now you're talking about writing ChangeLog-style *entries* (which could be done in commit messages), not really about ChangeLog files, as the immediately
  previous two paragraphs had been talking about, with no indication in between that some kind of conceptual transition had been made.

Do you see now why it at least looks like you're conflating these two different things?  Maybe you didn't mean to do so, but Paul's interpretation was reasonable; he was not quoting you in a misleading way.  When I read your original post, I already got confused by the conflation.  It wasn't Paul's followup that made me think that.  Paul and I came to the same conclusion for a reason.

Best regards,
-Karl