bug-standards
[Top][All Lists]
Advanced

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

Re: Script to generate ChangeLogs automatically


From: Joseph Myers
Subject: Re: Script to generate ChangeLogs automatically
Date: Wed, 5 Dec 2018 00:48:22 +0000
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

On Wed, 5 Dec 2018, Richard Stallman wrote:

> More precisely, how far we can _reduce_ what we require a user to know,
> to do those things?

For example, we have the rules on comments that mean in many cases the 
required information should be in a comment and it shouldn't be necessary 
to refer to the history at all in those cases - many bug fixes or new 
features don't require referring to the history.  I'm not proposing any 
change to the expectations on comments.  We take ensuring proper comments 
seriously in glibc patch review, especially in tricky areas such as atomic 
operations and synchronization.

For example, many projects expect various classes of changes to add tests 
to the automated testsuite.  In that case, someone wondering why some code 
is there can try changing it and seeing if any tests fail.

For example, many projects have their own guidance on how to work with 
their repositories, which may include example git commands.  (Even with a 
perfectly intuitive version control system everyone is fully expert in, 
such guidance would still be needed, simply to document things such as 
branching conventions.)

For example, many projects have documentation of internals such as how the 
source tree is arranged.

For example, there are various ways in which someone running into 
difficulty can ask for help with their particular task (on the libc-help 
mailing list or #glibc IRC).

It's not at all the case that someone wishing to fix a bug would need to 
be an expert in git in the absence of ChangeLogs; there are many sources 
of information, both on the design and motivation of particular code and 
on how to work with the source tree and the repository, and many ways for 
non-experts to get started and make progress.  Sometimes a particular 
history investigation might prove to be trickier and need more expertise, 
but then sometimes a particular bug fix might also turn out to involve 
tricky issues as well and so be unsuitable for a beginner.

-- 
Joseph S. Myers
address@hidden



reply via email to

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