Re: Script to generate ChangeLogs automatically

[Joseph Myers]

On Sat, 1 Dec 2018, Richard Stallman wrote:

>   > You need to know some C to contribute to a package written in C.  
>   > Similarly, I think it's reasonable to expect knowledge of some git to 
>   > explore the history of a package using git.
> 
> Those two issues look similar at a superficial glance, but they are
> fundamentally very different.  It is impossible to understand a
> program without knowing the language it is written in.  But git is
> just a development tool.  It is only marginally necessary -- not
> crucial.

I think some version control system is crucial for large-scale software 
development - meaning the version control system used by the project you 
are working on (modulo the ability to use e.g. git-svn to have access to 
git facilities when using a project hosted in SVN - which many people do, 
because they want the greater power and familiarity of git).

Likewise, a bug tracker.

Likewise, some means of having development discussions around proposed 
changes, whether that's a mailing list, a pull-request based system, or 
some other arrangement for discussions.

Likewise, the ability to search past discussions in those places.

(I know you've said in 
<https://lists.gnu.org/archive/html/bug-standards/2018-01/msg00023.html> 
that mailing list archives and bug trackers are "too much trouble to 
access", but I think that's very far off the mainstream of free software 
development, where while people might occasionally be developing offline, 
e.g. replying to email offline while on a plane, the vast bulk of the time 
they have a browser immediately to hand, and find their development work 
substantially handicapped on the occasions when they are working offline 
without access to those resources.)

Some system for real-time communication (glibc has #glibc IRC on freenode) 
is also very valuable.  The typical developer having trouble using git to 
explore history can ask for immediate help there.

I agree with Carlos that future new GNU developers will all have a working 
knowledge of git.  We should be looking to the tools that future 
developers will be using when designing the standards, not to those that 
developers are used to from the past - rejecting tools that are non-free, 
accepting tools that improve the power of our development environment 
without being adverse to principles of software freedom.

I think that we should respect the experience of non-GNU free software 
developers managing very large non-GNU projects (e.g. the Linux kernel) 
with the above tools, but not using ChangeLog format, as a proof by 
example that ChangeLog format is not required to be able to answer all the 
questions about the history of the code that arise in practice in 
development.  There are often complaints about the Linux kernel not 
consistently using issue tracking; before it used version control, and 
when it used non-free version control, there were complaints about that; 
but git works very well for the Linux kernel (having been designed for 
it!), without needing ChangeLog format.

> In any case, remember that the problem with git is that its commands
> to study the history predictably fail in certain cases.

Predictable failing (because the tool does some well-defined thing and a 
user can understand what that is, and the failure cases) can be better 
than unpredictable failure (because the tool tries to handle too many 
special cases).

> The program I want people to write would work around that failure.

You said a program needs to give "correct output in all cases that can 
appear in glibc" 
<https://lists.gnu.org/archive/html/bug-standards/2018-11/msg00012.html>.

Apart from being a stronger requirement than previously stated in 
<https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00011.html> 
"reliably enough that errors are rare and not a problem", it's not one the 
maintainers can realistically confirm to be met, simply because there are 
too many source files (17000), many of which none of the current 
maintainers are familiar with.  Such a standard would effectively prevent 
any large, longstanding GNU project whose maintainers have changed over 
the years from using such a program.

I think the GNU project should trust package maintainers *more*, not less 
- delegate more to them regarding technical decisions of when particular 
scripts or means of using version control are sufficiently good for 
understanding the package history.

-- 
Joseph S. Myers
address@hidden