[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
- Re: Using VC for change descriptions, (continued)
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/28
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/28
- Re: Using VC for change descriptions, Mike Gerwitz, 2018/01/10
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/07
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/07
- Re: Using VC for change descriptions, Joseph Myers, 2018/01/09
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/07
- Re: Using VC for change descriptions,
Joseph Myers <=
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/07
- Re: Using VC for change descriptions, Joseph Myers, 2018/01/09
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/07
- Re: Using VC for change descriptions, Paul Eggert, 2018/01/07
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/08
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/07
- Re: Using VC for change descriptions, Joseph Myers, 2018/01/09
- Re: Using VC for change descriptions, Richard Stallman, 2018/01/14
- Re: Using VC for change descriptions, Joseph Myers, 2018/01/15
- Re: Using VC for change descriptions, Joseph Myers, 2018/01/15