Re: Circumstances in which ChangeLog format is no longer useful

[Joseph Myers]

On Tue, 1 Aug 2017, Alfred M. Szmidt wrote:

>    $ git log --grep=NFPREG
>    $ git log -E --grep='N(FP|G|VR)?REG'
>    $ git log --grep=NFPREF -p
>    $ git log --grep=sysdeps/arm/sys/ucontext.h [-p]
>    $ git log -G'fpregs' -p
> 
> And what about non-git?  Should we list every magical invokation for
> every VCS that is in use?  An extracted ChangeLog works for anyone and

No, we should expect people to learn whatever tools are appropriate for 
working on the projects they are developing.  It's not the place of the 
GNU Coding Standards to tell people how to extract particular information 
from version control history.  And I'd expect most git guides to 
concentrate on things such as git bisect, because I'd expect "find the 
revision that introduced a bug" to be a more common issue than "find all 
changes affecting a symbol called X, across all source files".

> everyone.  People who keep suggesting git as a solution miss the point

The ChangeLog works only if they have questions at an extremely specific 
level (wanting human-readable descriptions of changes split up into how 
individual named entities are changed, but not the associated diffs or 
source tree versions, relating to changes that can readily be described at 
that level)

> of being able to extract this information in a archivable format.

You could have a -with-history.tar.xz tarball if desired, including the 
git history (or simply ship the log of *logical-level* commit messages in 
tarballs, without trying to decompose descriptions of complicated global 
changes into per-named-entity fragments).

For people to follow development history properly requires the actual VCS 
history, not just logs (any forms of logs).  And the mailing list 
archives, and the issue tracker, and quite likely other tools such as 
patch review systems.  I fully encourage the development of tools for 
export of such rich structured data for free software projects, in a form 
that can be imported into another free software development site, as well 
as the development of software for free software hosting sites that 
supports such import and export of structured data.  (Cf. ESR's past blog 
postings about the problems with software forges not supporting such 
export.)  I do not think requiring use of a particular text format for a 
very limited subset of the history information is a useful part of 
ensuring the development history of free software projects remains readily 
accessible in future.

-- 
Joseph S. Myers
address@hidden