Re: Is it time to drop ChangeLogs?

[Ted Zlatanov]

On Sat, 09 Jul 2016 12:54:48 -0400 Richard Stallman <address@hidden> wrote: 

>> This can easily be encoded in a database table so it's searchable,
>> indexed by symbol name or file name (to build a history), etc. as part
>> of the pull request system. It can be semi-automatic: the system figures
>> out the file and symbol changes, then the developer adds the rest (and
>> the review doesn't end until this is done).

RS> Given a program that can determine which function or entity name
RS> to associate with each line, it would not be hard to make a list of
RS> which entities are changed in a given patch.

RS> Do we have such a program?  I don't know that we do.

RS> However, determining what kind of change was made to a certain entity
RS> in a certain patch is much harder.  Consider this:

RS> * file.c (create_swimming_pool): New function
RS> (modernize_building): Call it.

RS> How would a program decide whether "Call it." is enough to say about
RS> the change in modernize_building, or whether it is necessary to say
RS> more?

You're right, of course. But I wasn't saying the program would do the
entire job. It will know *what* has changed and provide a place to enter
the *why* messages. Then the code reviewer will require those messages
before approving the merge. That's essentially what ChangeLogs do, but
this will be in a structured format so it's easier to index and analyze
the data.

A good first iteration of this would be a mechanism to generate the
structured data from a patch/diff, which would then hook into the
current mechanism to generate ChangeLog-style entries in the commit
message. (Currently this is a mostly manual process, I believe.)

That would benefit everyone right away by speeding up the ChangeLog
format generation, and can then be used for the more elaborate system
when and if we decide.

Ted