Re: Is it time to drop ChangeLogs?

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 07 Jul 2016 22:57:46 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Problem is, I don't find the subtle fine points that need addressing
EZ> until I actually apply the patch: compiler warnings, code not
EZ> according to our conventions, sometimes patch won't apply, etc.

Typically this is addressed with a build system that takes every pull
request and builds it, logging problems right into the pull request.

EZ> All the other projects I
EZ> participate in make it harder, and yet no one complains or thinks they
EZ> are hard on contributors.

I think there is a confirmation bias there: people tend to believe the
feedback that confirms their existing views and discount the opposite.

On Fri, 08 Jul 2016 12:28:32 +0100 phillip.lord@russet.org.uk (Phillip Lord) wrote: 

PL> I think that the discussion is bottoming out here. If there is interest,
PL> I will be happy to investigate some of the options and produce a report
PL> of pros and cons. Alternatively, if the general feeling is, it's all
PL> fine, then no worries, I'll leave it.

On Fri, 8 Jul 2016 02:50:31 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote: 

DG> That said, before continuing this discussion, I'd rather we switch to a
DG> modern-ish bug tracker first.

As I said, I'll try using the (painful) bug tracker to do code reviews.
Please consider me strongly in favor of a better code review system and
a better bug tracker. Ideally they would be one and the same.

On Thu, 07 Jul 2016 17:56:01 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> Are you saying that most projects do not keep track of which functions
RS> are changed in each commit?

RS> How can maintainers figure out how to solve problems without detailed
RS> log records to show them which previous changes they need to study?

The code review (pull request handling) system has all that information.

For instance, you can search for error messages, not just the commits
that fixed them. The real value emerges when the entire development
workflow is captured in the same place, indexed for searching, and open
for world-wide review and contribution.

>> The pull request system can later provide *everything* that a
>> ChangeLog could,

RS> I am skeptical of this claim.  How precisely will the pull request system
RS> provide what we now get from the detailed lists of objects changed
RS> in the log entries?

The ChangeLog structure is something like this:

top-level-message
  file1: message1
    symbol1: message11
    symbol2: message12
  file2: message2
    ...

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).

The database can be part of the Emacs Git repository, it doesn't have to
be something magical outside it. But that's an architectural decision.

The end result is a lot like the ChangeLog format we have today...
except it's structured data, linked to a *series* of commits *and* the
code review on them.

That piece doesn't exist, but I'm willing to bet that developing it is
*much less* work than the man-hours that will be spent crafting the
ChangeLog format over the coming years. Consider as well that it will be
useful to the whole GNU project, not just Emacs.

Ted