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 [email protected]
