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?

if 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

