From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Kenichi Handa <handa@ni.aist.go.jp>
Newsgroups: gmane.emacs.devel
Subject: How to re-orgranize ChangeLog.unicode for merging
Date: Mon, 12 Nov 2007 14:17:13 +0900
Message-ID: <E1IrRfd-00037C-Sv@etlken.m17n.org>
References: <m21wb3vayb.fsf@news.cyberhut.org>
	<47305F6E.2030204@gnu.org>	<m2fxzjw4xu.fsf@lifelogs.com>	<loom.20071107T111446-237@post.gmane.org>
	<4731D43F.3060007@gnu.org>	<jwvbqa6oxea.fsf-monnier+emacs@gnu.org>	<E1IpzDv-00082q-3D@fencepost.gnu.org>	<200711081556.lA8Fulm5016419@oogie-boogie.ics.uci.edu>	<E1IqLEN-0006Vk-3Y@fencepost.gnu.org>	<200711090747.lA97loNF007692@oogie-boogie.ics.uci.edu>	<uwssrpv01.fsf@gnu.org>	<200711091509.lA9F9cj0017064@oogie-boogie.ics.uci.edu>
	<E1IquXe-0000O8-MP@fencepost.gnu.org>
NNTP-Posting-Host: lo.gmane.org
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Trace: ger.gmane.org 1194844712 2705 80.91.229.12 (12 Nov 2007 05:18:32 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 12 Nov 2007 05:18:32 +0000 (UTC)
Cc: Adrian.B.Robert@gmail.com, eliz@gnu.org, dann@ics.uci.edu,
	emacs-devel@gnu.org
To: rms@gnu.org
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 12 06:18:35 2007
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([199.232.76.165])
	by lo.gmane.org with esmtp (Exim 4.50)
	id 1IrRgx-0003Yy-3y
	for ged-emacs-devel@m.gmane.org; Mon, 12 Nov 2007 06:18:35 +0100
Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43)
	id 1IrRgk-000217-P7
	for ged-emacs-devel@m.gmane.org; Mon, 12 Nov 2007 00:18:22 -0500
Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IrRgM-0001xj-QB
	for emacs-devel@gnu.org; Mon, 12 Nov 2007 00:17:58 -0500
Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IrRgL-0001x7-HG
	for emacs-devel@gnu.org; Mon, 12 Nov 2007 00:17:58 -0500
Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IrRgL-0001wu-9U
	for emacs-devel@gnu.org; Mon, 12 Nov 2007 00:17:57 -0500
Original-Received: from mx1.aist.go.jp ([150.29.246.133])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <handa@m17n.org>)
	id 1IrRfy-0003ex-NL; Mon, 12 Nov 2007 00:17:47 -0500
Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115])
	by mx1.aist.go.jp  with ESMTP id lAC5HFX6002868;
	Mon, 12 Nov 2007 14:17:15 +0900 (JST) env-from (handa@m17n.org)
Original-Received: from smtp1.aist.go.jp
	by rqsmtp1.aist.go.jp  with ESMTP id lAC5HEHV006629;
	Mon, 12 Nov 2007 14:17:14 +0900 (JST) env-from (handa@m17n.org)
Original-Received: by smtp1.aist.go.jp  with ESMTP id lAC5HDWr003958;
	Mon, 12 Nov 2007 14:17:13 +0900 (JST) env-from (handa@m17n.org)
Original-Received: from handa by etlken.m17n.org with local (Exim 4.67)
	(envelope-from <handa@m17n.org>)
	id 1IrRfd-00037C-Sv; Mon, 12 Nov 2007 14:17:13 +0900
In-reply-to: <E1IquXe-0000O8-MP@fencepost.gnu.org> (message from Richard
	Stallman on Sat, 10 Nov 2007 12:54:46 -0500)
User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2
	Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
X-detected-kernel: by monty-python.gnu.org: Solaris 8 (1)
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Xref: news.gmane.org gmane.emacs.devel:83018
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/83018>

I have a few questions about how to re-orgranize
ChangeLog.unicode for merging.

(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.

(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.

(3) RMS wrote:

  > The most important part of the massaging is to get rid of duplicate
  > entries.  For instance suppose a function named foo is added and then
  > changed 10 times.  There will be 11 change log entries for it, but we
  > we only need to keep one: "New function".

Even for a new funciton, I want to know why some piece of
code is in the current shape.  I many times encountered such
a case that I don't remember why I wrote some code as the
current way.  In such a case, I read changelogs and get a
hint.  So, I don't want to loose the current information.
If you don't insist on having just one entry for changes of
a non-new function, please apply that also to a new
function.  For instance, I want to keep all of these
information.

	(insert_from_gap): Adjust intervals correctly.
	(insert_from_gap): Fix argument to offset_intervals.
	(insert_from_gap): Make it work even if PT != GTP.
	(insert_from_gap): Call record_insert.
	(insert_from_gap): New function.

Then, for instance, I can know (or recall) that the function
is intentionally coded to work in the PT != GTP case.

---
Kenichi Handa
handa@ni.aist.go.jp