From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: How to re-orgranize ChangeLog.unicode for merging Date: Sun, 18 Nov 2007 17:47:01 -0500 Message-ID: References: <47305F6E.2030204@gnu.org> <4731D43F.3060007@gnu.org> <200711081556.lA8Fulm5016419@oogie-boogie.ics.uci.edu> <200711090747.lA97loNF007692@oogie-boogie.ics.uci.edu> <200711091509.lA9F9cj0017064@oogie-boogie.ics.uci.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1195426640 10543 80.91.229.12 (18 Nov 2007 22:57:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2007 22:57:20 +0000 (UTC) Cc: Adrian.B.Robert@gmail.com, eliz@gnu.org, dann@ics.uci.edu, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 18 23:57:25 2007 Return-path: 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 1Itt4u-0006aU-NR for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2007 23:57:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Itt4h-0007KO-61 for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2007 17:57:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Itsuu-0001hB-Po for emacs-devel@gnu.org; Sun, 18 Nov 2007 17:47:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Itsut-0001f1-Ml for emacs-devel@gnu.org; Sun, 18 Nov 2007 17:47:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Itsut-0001en-Bw for emacs-devel@gnu.org; Sun, 18 Nov 2007 17:47:03 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Itsut-0002o4-26 for emacs-devel@gnu.org; Sun, 18 Nov 2007 17:47:03 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Itsur-0003KH-Gs; Sun, 18 Nov 2007 17:47:01 -0500 In-reply-to: (message from Kenichi Handa on Mon, 12 Nov 2007 14:17:13 +0900) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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:83586 Archived-At: (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 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 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.