[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
- Re: Using VC for change descriptions, (continued)
- Re: Using VC for change descriptions, Paul Eggert, 2017/11/26
- Re: Using VC for change descriptions, Mike Gerwitz, 2017/11/27
- Re: Using VC for change descriptions, John Darrington, 2017/11/27
- Re: Using VC for change descriptions, Joseph Myers, 2017/11/27
- Re: Using VC for change descriptions, Richard Stallman, 2017/11/28
- Re: Using VC for change descriptions, John Darrington, 2017/11/28
- Re: Using VC for change descriptions, Joseph Myers, 2017/11/28
- Re: Using VC for change descriptions, Mike Gerwitz, 2017/11/28
- Re: Using VC for change descriptions, Joseph Myers, 2017/11/27
- Re: Using VC for change descriptions, Mathieu Lirzin, 2017/11/27
- Re: Using VC for change descriptions,
Joseph Myers <=
Re: Using VC for change descriptions, Richard Stallman, 2017/11/26
Re: Using VC for change descriptions, Richard Stallman, 2017/11/27
Re: Using VC for change descriptions, Paul Eggert, 2017/11/27