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, 15 Jan 2018 13:53:26 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Sun, 14 Jan 2018, Richard Stallman wrote:

> I emphasize _see and judge_ because this has to be the conclusion of
> my own judgment.  You can't convince me by arguing, but my own
> experience might.

By far the best way of getting that experience is through deliberately 
using git instead of ChangeLog entries for some time when looking at 
software history (asking other people in any case where you don't see how 
to address your problem using git).

But another approach is to look at the development of a large, complicated 
non-GNU free software project that does not use ChangeLogs, such as the 
Linux kernel, and look for any cases where developers are finding they 
have difficulty in adding a feature or fixing a bug because of the lack of 
lists of changed entities for past changes.  If git-based workflows work 
well for such a project with hundreds of thousands of commits, that is 
very strong evidence of their suitability.

> It might be necessary to improve the tools so that they are adequate
> in _all_ cases, not just usually.

"adequate" should mean adequate for solving the underlying problems - for 
fixing bugs and adding features to GNU software, and for investigating the 
history when that's relevant to doing so - not for a particular 
intermediate step in a particular workflow.  I think the git-based 
workflow is indeed fully adequate (and that deliberately making use of it 
for some time would provide experience of how it's fully adequate).

ChangeLogs are far from adequate in all cases - in many cases you need the 
actual diffs for individual changes and the exact sources of past versions 
for bisection.  I think the relevant question should be what is on balance 
better for GNU package development (taking into account opportunity costs, 
such as the improvements to GNU packages that are not made because of the 
time spent writing ChangeLog entries for other patches).

-- 
Joseph S. Myers
address@hidden



reply via email to

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