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: Tue, 9 Jan 2018 17:28:41 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Sun, 7 Jan 2018, Richard Stallman wrote:

>   > > A ChangeLog entry is far easier to process by a human, than a large
>   > > diff.  For some languages the diffs become really ugly, specially for
> 
>   > A logical description of the change at an appropriate level for that 
>   > change is even easier for a human to process than the ChangeLog entry.  
> 
> What you said is not false, but you've altered the question under
> discussion.  AMS was comparing two ways of finding out which functions were
> changed and how.  The high-level-only change description does not try
> to help do that job.  If we were to adopt your proposal to stop recording
> entity names in the history, the history would no longer be an option
> for the job in question.

Which I don't think is actually a job we should be trying to address other 
than as a means to other jobs.

The underlying tasks in GNU package development are such things as finding 
and fixing bugs, adding new features, becoming familiar with the code as a 
new developer.  Tools such a version control should be helping with those 
goals.  When people are looking at which functions changed and how, we 
should look at the underlying tasks and make sure there are appropriate 
alternative ways to address those tasks not requiring ChangeLog format, 
which may or may not incidentally involving identifying changed functions 
in another way.

>   > 4. The mailing list archives, bug tracker etc. with all the surrounding 
>   > development discussions.
> 
> No, that's too much trouble to access.  So slow, and so much trouble,
> that I would never even try.

That's completely opposite to my experience - it's routinely the case when 
working on a GCC bug that I find useful information from web searches 
(restricted with site:gcc.gnu.org) for things that seem relevant, or in 
Bugzilla, or through grep of my local mailbox copies of the mailing lists, 
or a combination of those.  Bug trackers are a fundamental tool for 
tracking known issues and finding discussions of such issues and of those 
issues fixed in the past.

-- 
Joseph S. Myers
address@hidden



reply via email to

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