Re: changelog format

[Karl Berry]

Some quick comments on all, but see end before replying :).

    1 -- Expand "other files for which changes should be logged" to say
         explicitly "media files" instead of "help files".

Should be no problem.

    2 -- Clarify "change log entry", making a distinction between a "change
         set" (introducing this term) and an "individual change".  

I am not enthused about the term change set, but I have nothing better
to suggest.

    A single change log entry corresponds to a change set, which
    comprises one or more individual changes.

Should be no problem, since that has always been the intent.  So you're
just talking about clarifying wording here.

     - files that don't support comment syntax (e.g., media files);
     - a large change set, where something like:

Sounds fine.

    4 -- Suggest TITLE (aka DESCRIPTION LINE) format; keep it optional.

Sounds fine.  I've seen rms write some "description line"s in ChangeLog
entries recently :).

100% agreed it should be optional.  In my own experience, there are
plenty of times when writing a description line would just be useless
noise.

    5 -- (in line with 3, dependent on 4) Encourage "moderate" reference

Encouraging "moderate" reference information in general sounds ok.  I
don't know about any standardized format, since packages handle bug
reports in soooo many different ways.  For example, for Texinfo, I
sometimes give a Debian bug reference if that's where it came from.  Or
I use something like this for things which just come in email:

  bug-texinfo 11 Mar 2012 21:17:45.

Which for all practical purposes is a unique id that is easily located
(much more easily than the message-id), but is hardly anything that
should be standardized.

    Anyway, now i'll submit the above pieces in new threads, starting w/
    0 and waiting to conclude one before starting another -- Karl: is
    that the best way?

Yes, I think that is the best way forward.

Thanks,
Karl