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: John Darrington
Subject: Re: Using VC for change descriptions
Date: Wed, 10 Jan 2018 11:43:05 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Jan 09, 2018 at 11:07:11PM -0800, Paul Eggert wrote:
     Richard Stallman wrote:
     >for the idea of using these diffs in a script to generate a
     >list of the entities changed in a given commit, the script needs to
     >deal with this quirk.
     >
     >Want to write it?
     
     No thanks. I have quite a bit of experience writing scripts to generate
     ChangeLog files -- I daresay more experience than anyone else
     contributing to this thread -- and this experience suggests that the
     proposed task is a lost cause. We cannot automatically generate
     ChangeLogs as "good" as the ones written by hand, and we shouldn't waste
     time trying. (By "good" I mean good for the traditional purposes that
     ChangeLogs were used for. For most of us I think these purposes are now
     largely superseded by version-control tools.)

This argument is going in circles.

There are three questions which we originally raised:

1.   Do we need changelogs at all?

2.   If the answer to 1 is "yes", then do we need to continue to 
     record each changed entity (function, variable etc) in the log?

3.   Is it possible to generate ChangeLogs from the VCS, so as to avoid
     having to maintain a separate file.


I think we have agreed that the answer to 1 is "yes".  I think there is
a body of opinion that thinks the answer to 2 is also "yes".

So far as 3 is concerned there are two possibilities under discussion:

a) A fully automated system, where some clever program will automatically
   infer the names of functions, variables etc which have changed.

b) Simply require that the commit message of the VCS takes the same format
   and information that we currently use for the ChangeLog entry, and auto
   generate the ChangeLog using the message previously entered by the committer.

I think that a) would be non-trivial.  But b) would indeed be trivial.  Why 
don't
we allow maintainers (at their option) to do the 3b approach?  

Richard, what do you think of that?

J'

     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature


reply via email to

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