Re: How to re-orgranize ChangeLog.unicode for merging

[Richard Stallman <rms@gnu.org>]

    (1) As emacs-unicode-2 branch has very long history, the
    changes have been made not only by me.  If the same function
    has been modified by multiple persons, should we sumup
    changes for each person?  If so, the result will be
    confusing because we loose the time-line of changes.

    DATE1 CHANGE1 by A
    DATE2 CHANGE2 by B
    DATE3 CHANGE3 by A
    DATE4 CHANGE4 by B

    will result in:

    by A
      CHANGE1
      CHANGE3
    by B
      CHANGE2
      CHANGE4

    But, usually, it's important to know that CHANGE4 is done
    after CHANGE3.

We should not combine change log entries for two different people.
Each change should be assigned to the correct person.

It is not necessary to preserve the time line of changes in the
simplified change log.  Rather, we think of this as a single change
being installed all at once.  So we will redate the new change log
entries to date these changes are installed in the trunk.

We will preserve permanently the original ChangeLog file for the
unicode-2 branch for whenever someone wants to know the precise
history of the writing of those changes.

    (2) The log files contain this kind of information.

    2007-02-15  Kenichi Handa  <handa@m17n.org>

	    These changes are to compile a regexp into a pattern that can be
	    used both for multibyte and unibyte targets.

	    * Makefile.in (search.o): Depend on charset.h.
	    ...
    [...]
    2006-06-06  Kenichi Handa  <handa@m17n.org>

	    These changes are for the new font handling codes.

	    * character.c (multibyte_char_to_unibyte_safe): New function.
	    ...

    How to keep this kind of summary information when we sum up
    changes.

Most of these items won't be combined away, so they will stay where
they are and you can leave them after the summaries.  The few
exceptions usually won't matter; but if you think one is important,
you can leave it unchanged and uncombined.