From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: please consider emacs-unicode for pervasive changes Date: Wed, 24 Jul 2002 23:30:56 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027567935 9727 127.0.0.1 (25 Jul 2002 03:32:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 25 Jul 2002 03:32:15 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17XZML-0002Wl-00 for ; Thu, 25 Jul 2002 05:32:13 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XZbR-0007cH-00 for ; Thu, 25 Jul 2002 05:47:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XZMY-0004NS-00; Wed, 24 Jul 2002 23:32:26 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XZLF-0004MR-00 for ; Wed, 24 Jul 2002 23:31:05 -0400 Original-Received: from kal-el.raeburn.org ([2002:d03b:b25a:1:201:2ff:fe23:e26d]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g6P3Uvf17949; Wed, 24 Jul 2002 23:31:02 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17XZL6-0005J5-00; Wed, 24 Jul 2002 23:30:56 -0400 Original-To: Dave Love In-Reply-To: (Dave Love's message of "24 Jul 2002 00:24:10 +0100") Original-Lines: 117 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.3.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6023 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6023 I had written up a reply earlier, and Emacs crashed in the display code, though I haven't figured out why yet. I wonder if it's a sign... Dave Love writes: > I'm not at all surprised, but that's not the point. You're one of the > people I expected actually to understand what such changes entail > practically when it comes to a merge, but it wasn't directed just at > your changes. Even things like straight global exchanges cause > problems in the end. Yes, you _can_ go through all the changes, try > to understand them, and try to duplicate more-or-less the work that > was done originally. But. Yes, "but". It's tedious work, whoever does it, and whichever direction it's going, and unless you've got someone who understands both sets of changes, merging them can be a problem. I haven't yet had a positive experience with extended development using branches. Deciding who merges what and when is what's at issue. Are we talking about general policy for Emacs work, or special treatment for the Unicode branch? I haven't heard much about either. Fortunately, in my case, most of my string-macro changes don't actually require much understanding of the surrounding context; it's a simple transformation on C source code. So I probably could merge my bigger recent changes into your branch without needing to understand the overall gist of your changes. > If you want to improve the GC (which would be very useful) what's the > reason for not trying the Boehm collector, as TODO suggests? The This came up on emacs-hackers a few months ago. Improving the GC would be useful, but only if we decide we're not switching to Guile any time soon. If that happens, I'd probably be more interested in working on fixing Guile, but I could probably be convinced to help with more write-barrier stuff if someone else wanted to do the Emacs GC work. > I doubt that's worthwhile for changes that don't go anywhere near Mule > unless they're fixing things which make it difficult actually to run > the branch version (which is the reason I looked at trying to merge > changes which might help). Can you describe "anywhere near Mule" a little more carefully? Or should I just run some cvs diffs on your branch to see if you've touched the code I want to touch? >> I've assumed that when I start work on a Guile branch, I'd be >> responsible for dealing with merges in both directions and all the >> coordination that implies. > Well, I'll give up at that stage. I'm assuming it because I've heard nothing else about "how we manage development branches in Emacs". Perhaps RMS simply doesn't want a blanket policy right now. Or maybe it hasn't been advertised well enough in places where I've been looking. >> It would be helpful for automatic tools or other useful techniques to >> be made available, > I don't know what tool support could help. I think it's basically a > question of management. I was thinking of things like the lisp code I used to make some changes. Or easy manual techniques for finding where certain changes need to be made in the code. Perhaps not applicable to most cases, but when they are, sometimes they're for pervasive changes like mine. >> but I wouldn't want to demand that everyone making >> big changes on the trunk also be required to know which branches are >> "active" and how their changes might have to be applied differently to >> those branches, and rewrite their changes to suit. > I disagree. ``CVS is not a substitute for management.'' So you think I need to understand your Unicode work, and Miles's lexbind work (looks like he's added another field to Lisp_Symbol), and whatever else might be "active" now, and merge any widespread changes I make that might affect them onto N branches? Or do you just want special treatment for the Unicode branch? Can we write up somewhere what's being done on branches that developers need to be aware of, and when a developer should apply changes to which branches? Otherwise, how is someone who joins this list next week going to know? >> If you get around >> to merging in some big changes to the trunk to change the >> character-data handling in ways that better support the Unicode >> changes -- or perhaps the completed set of Unicode changes -- > You mean there's some question about that happening, other than the > resources to do it which concerned me? That's not what I understood > when I was pressed to do the Mule work. Poorly phrased, sorry. I should have said, "If, when you do the merging, there's a Guile branch..." I don't know *how* you're going about the Unicode work, particularly handling merges. Apparently it involves getting other people to help with some of the merging. >> would you want to be required to merge them onto a Guile branch as >> well? > I'm afraid I don't want to waste my time on things related to Guile. > If we're competing against that, I'm going to stop. If you think Guile is a waste of time, I'm sorry to hear it. I don't plan to stop any time soon. But I don't think that means there's any sort of "competition" here. And Guile wasn't the point of my question, anyways. Assume for the sake of argument that when you're ready to merge the Unicode changes, there's some big, important, non-Guile-based branch that's also been started by someone other than me, and it'll be affected by the Unicode changes. Do you think you should to be asked to merge the Unicode changes onto that branch? Ken