[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preview: portable dumper

From: Daniel Colascione
Subject: Re: Preview: portable dumper
Date: Wed, 30 Nov 2016 21:12:35 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/30/2016 08:49 PM, John Wiegley wrote:
Daniel Colascione <address@hidden> writes:

If that's your decision, I'm going to fork.

I'm quite sorry to hear it, but if branches are unacceptable, then such is
your right as a free software developer.

Branches in general are fine. Relegating this specific feature to a branch feels political.

I would very much prefer to continue improving GNU Emacs. I'm a longtime fan of the GNU Project. But I feel like the current gatekeepers are standing in the way of progress. We can't even make the conservative GC safe in the face of foreseeable compiler optimizations. This isn't the first time that I've gotten a flat "no" in response to a good idea. If I do fork, I can incorporate many more kinds of experimental work. One of the first things I'd consider would be an LLVM-based tracing JIT.

Let me try one last time to explain my position: this dumping code will make no Emacs no worse. It cannot possible destabilize Emacs when it is compiled out of Emacs at configure-time. I specifically designed this feature to be optional. I am perfectly happy merging my code in such a way that it is not compiled into Emacs by default, and I am perfectly happy waiting until we've gotten sufficient testing before enabling the portable dumper.

In the miraculous case that someone contributes an lread optimization that allows that the big-ELC approach to perform as well as a memory image, I will happily back out of my code.

But because this code is harmless when compiled away and because we can back it out without problems, I see the requirement that we put this code into a branch as a way to kill the feature. If this code were more fundamentally destabilizing, I would feel different --- but as it is, since this code is *not* fundamentally destabilizing, I don't see a technical case for a feature branch.

I am perfectly happy with a six month or longer timetable for enabling this code at ./configure time. I expected as much. The XEmacs experience with their portable dumper (which I have not read) was similar. I specifically designed this code to be compatible with the current implementation and to allow for a gradual transition.

Is anyone else signing up to make Emacs work better on modern systems?

Just so you know, I'd hope to see your patches on master within six months,

What specific conditions need to be met before merging? Why can't I meet these requirements before landing the diff? This code will never meet the "nobody has complained" requirement. It's going to have to land over some objections, because some contributors object to the very essence of the change. If there are technical requirements, why can't I meet these requirements before landing this work in master? If there are political requirements, what makes you think that a branch would help me meet them?

we can find some willing testers (and one has already stepped forward). The
only way your changes *wouldn't* land is if a better alternative comes along
in the meantime -- which, of course, would mean we all win.

What is the fundamental difference between merging this code into mainline in a disabled-by-default configuration and merging it into a branch, except that it's much more convenient to try the feature in the former case?

I don't suppose I can encourage you to maintain your fork within the Emacs.git
repository? There this thing, rhymes with "blanch", where you could work on
your version in tandem, even merge changes from us every once in a while... :)

There have been cries to adopt a more modern development style, one focused on GitHub and pull requests. I can certainly accommodate.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]