all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
Cc: emacs-devel@gnu.org
Subject: Re: please consider emacs-unicode for pervasive changes
Date: Wed, 24 Jul 2002 23:30:56 -0400	[thread overview]
Message-ID: <tx1it34fpqn.fsf@raeburn.org> (raw)
In-Reply-To: <rzqy9c26nad.fsf@albion.dl.ac.uk> (Dave Love's message of "24 Jul 2002 00:24:10 +0100")

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 <d.love@dl.ac.uk> 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

  parent reply	other threads:[~2002-07-25  3:30 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-18 16:02 please consider emacs-unicode for pervasive changes Dave Love
2002-07-18 16:44 ` Stefan Monnier
2002-07-19 16:53   ` Richard Stallman
2002-07-19 17:44     ` Stefan Monnier
2002-07-20  0:35       ` Richard Stallman
2002-07-20 22:07       ` Richard Stallman
2002-07-21  5:10         ` Eli Zaretskii
2002-08-09  7:56         ` Stefan Monnier
2002-08-10 17:16           ` Richard Stallman
2002-08-12 17:25             ` Luc Teirlinck
2002-08-13 22:47               ` Richard Stallman
2002-08-12 17:53             ` Tak Ota
2002-08-12 18:44               ` Stefan Monnier
2002-08-13 22:46               ` Richard Stallman
     [not found]                 ` <20020813.175221.107709446.Takaaki.Ota@am.sony.com>
2002-08-15 19:54                   ` Richard Stallman
2002-08-15 20:47                     ` Tak Ota
2002-08-16 14:31                       ` FSF Copyright Assignment Clerk
2002-08-16 17:59                       ` Richard Stallman
2002-08-16 18:32                         ` Tak Ota
2002-08-12 19:58             ` Simon Josefsson
2002-08-13 22:46               ` Richard Stallman
2002-08-14 11:52                 ` Simon Josefsson
2002-08-14 12:32                   ` Simon Josefsson
2002-08-14 23:14                   ` Richard Stallman
2002-08-31 17:12             ` Dave Love
2002-09-01  0:10               ` Alex Schroeder
2002-08-13 16:34     ` plan for code freeze Stefan Monnier
2002-08-14  5:15       ` Richard Stallman
2002-08-14 14:39         ` Stefan Monnier
2002-08-17  4:19           ` Karl Eichwalder
2002-08-17 20:08             ` Richard Stallman
     [not found]               ` <m2u1lsa3sx.fsf@primate.xs4all.nl>
2002-08-18 19:18                 ` Karl Eichwalder
2002-08-19  5:17                   ` Miles Bader
2002-08-19 20:46                     ` Richard Stallman
2002-08-19 21:55                       ` Alex Schroeder
2002-08-21  0:11                         ` Richard Stallman
2002-08-26  8:37                   ` Per Abrahamsen
2002-08-23 15:03               ` William M. Perry
2002-08-25  5:26                 ` Richard Stallman
2002-08-28 15:47                   ` William M. Perry
2002-08-29 17:50                     ` Richard Stallman
2002-08-29 17:53                       ` Stefan Monnier
2002-08-29 19:02                         ` Sam Steingold
2002-08-29 20:15                           ` Stefan Monnier
2002-08-29 20:25                             ` Sam Steingold
2002-08-29 20:36                               ` Alan Shutko
2002-08-29 20:38                               ` Stefan Monnier
2002-09-04 14:40                         ` William M. Perry
2002-07-18 18:39 ` please consider emacs-unicode for pervasive changes Ken Raeburn
2002-07-23 23:24   ` Dave Love
2002-07-24 15:54     ` Richard Stallman
2002-07-25  3:30     ` Ken Raeburn [this message]
2002-08-09  7:54     ` Stefan Monnier
2002-08-10 17:16       ` Richard Stallman
2002-08-12 20:08       ` Ken Raeburn
2002-08-13  0:30         ` Kenichi Handa
2002-08-31 17:07           ` Dave Love
2002-09-03  6:15             ` Kenichi Handa
2002-09-04 14:20               ` Richard Stallman
2002-09-05  5:48                 ` Kenichi Handa
2002-09-05 14:48                   ` Eli Zaretskii
2002-09-06  4:01                     ` Richard Stallman
2002-09-06  4:29                       ` Kenichi Handa
2002-09-07  3:17                         ` Richard Stallman
2002-09-09 22:17                           ` Dave Love
2002-09-19  4:59                             ` Eli Zaretskii
2002-09-25 22:49                               ` Dave Love
2002-09-19  4:57                       ` Eli Zaretskii
2002-09-20  3:43                         ` Richard Stallman
2002-09-25 22:39                           ` Dave Love
2002-09-06  4:46                     ` Kenichi Handa
2002-09-05 22:41                   ` Dave Love
2002-09-06  4:01                   ` Richard Stallman
2002-09-04 23:30               ` Dave Love
2002-09-05 18:03                 ` Richard Stallman
2002-09-05 20:42                   ` Kai Großjohann
2002-09-05 23:59                   ` Dave Love
2002-09-06 20:02                     ` Richard Stallman
2002-09-07 23:48                       ` Dave Love
2002-09-09  0:22                         ` Richard Stallman
2002-09-09  0:57                           ` Kenichi Handa
2002-09-09 23:33                             ` Richard Stallman
2002-09-12 23:01                               ` Dave Love
2002-09-13 19:33                                 ` Richard Stallman
2002-09-25 22:49                                   ` Dave Love
2002-09-27 17:42                                     ` Richard Stallman
2002-10-04 22:22                                       ` Dave Love
2002-10-06 16:14                                         ` Richard Stallman
2002-10-04  6:08                                     ` Kenichi Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tx1it34fpqn.fsf@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.