bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using VC for change descriptions


From: Joseph Myers
Subject: Re: Using VC for change descriptions
Date: Mon, 27 Nov 2017 15:31:18 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]