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: Merging multitty Date: Tue, 15 May 2007 05:46:41 -0400 Message-ID: References: <2wmz0iriyj.fsf@fencepost.gnu.org> <87fy65k6eh.fsf@red-bean.com> <853b25lk43.fsf@lola.goethe.zz> <86bqgr3g1h.fsf_-_@lola.quinscape.zz> <87k5vdse1d.fsf@catnip.gol.com> <17990.33223.288460.294949@kahikatea.snap.net.nz> <87ejlls8rl.fsf@catnip.gol.com> <464841DC.7040801@lorentey.hu> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1179222673 7977 80.91.229.12 (15 May 2007 09:51:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 May 2007 09:51:13 +0000 (UTC) Cc: nickrob@snap.net.nz, emacs-devel@gnu.org, miles.bader@necel.com, miles@gnu.org To: Karoly Lorentey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 15 11:51:11 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 1HntgQ-0007E4-GU for ged-emacs-devel@m.gmane.org; Tue, 15 May 2007 11:51:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HntoH-00027a-9x for ged-emacs-devel@m.gmane.org; Tue, 15 May 2007 05:59:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hntn4-00019A-09 for emacs-devel@gnu.org; Tue, 15 May 2007 05:57:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hntn2-00018T-Fz for emacs-devel@gnu.org; Tue, 15 May 2007 05:57:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hntn2-00018O-9n for emacs-devel@gnu.org; Tue, 15 May 2007 05:57:56 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HntfA-0002UK-KY for emacs-devel@gnu.org; Tue, 15 May 2007 05:49:48 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Hntc9-00009i-Lt; Tue, 15 May 2007 05:46:41 -0400 In-reply-to: <464841DC.7040801@lorentey.hu> (message from Karoly Lorentey on Mon, 14 May 2007 13:02:52 +0200) X-detected-kernel: 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:71100 Archived-At: The log was maintained in Emacs ChangeLog entry style, but in the Arch logs. Part of the merge effort is to convert these logs into flat ChangeLog files. That's very reasonable. They are not yet there, but they will be soon. That is good news. I think Miles was talking about the CVS log, not ChangeLog. These are two ways of representing the change log. Do you really think that the CVS log is not important? If it is acceptable to tell people, "don't look at the CVS log, always look at ChangeLog", then we could be sloppy about the CVS log. But I don't think the CVS log is that unimportant. I look there for info, and I think others do too. With all due respect, that seems an unreasonable request. The branch is more than three years old, with hundreds of documented changesets. The work of collating the change log entries will be much less than the work it took to write these change log entries in the first place. And that's not to mention the work of writing the code. Compared with the overall size of the task, this is small. Please don't make a disproportionate fuss over it. Do you have a tool to automatically convert ChangeLog files to individualized CVS logs? No, but if this would make the job easier, I am sure people can work on it. Note, however, that big simplifications are often possible when combining changes made over a long period. If a function is new in the multi-tty branch, the only change log it needs now is "new function". If you added on date A, and changed it on date B, the entry for date B can usually be deleted. I am not sure a program could make these simplifications.