Re: Is it time to drop ChangeLogs?

[Karl Fogel]

Eli Zaretskii <address@hidden> 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