On Mon, 27 Nov 2017, Mathieu Lirzin wrote: > Regarding the overall benefit of it, I think you miss the point that VCS > history (containing the diffs) is not distributed with the tarballs.
Since my concern is with the format rather than with the presence of a file named ChangeLog in releases, what exactly is included in release tarballs is peripheral to my point. It would be possible to have -with-vcs tarball variants that include the VCS history, or to include output of git log --stat in release tarballs (or --patch --stat if you want diffs there, given that the commit messages would be written on the basis that the reader can refer to the underlying diffs), or any number of such options. I don't think putting such information in tarballs is particularly useful, but I don't think it's particularly problematic either. > For the users the NEWS and ChangeLog files are their easiest way to The NEWS file is not affected at all by my proposal. It would still be included in release tarballs and would still have a description of changes at the user level, exactly as at present. (And it's more likely than ChangeLog files to get included in binary distributions such as in GNU/Linux distributions.) > understand why a function doesn't act as it previously does or a file > doesn't exist anymore when testing a new release. So IMO the benefit is > for the users not the maintainers. > > Having said that we could consider that the maintainer effort doesn't > worse the benefit of not requiring the user to download the whole VCS > repository (which can be huge with DVCS) even for small investigations. In practice it's likely users can browse the repository online, search for the development discussions that resulted in a change, etc., and do not actually need to download the whole history to investigate such a question. And if I reach the point of wanting to fix an issue that appeared in a new release, I'd expect to check out the development sources (and thus download the DVCS history), to make sure the issue actually appears there and so that the patch I submit is against the current development version rather than a release. -- Joseph S. Myers [email protected]
