Re: Preview: portable dumper

[Daniel Colascione]

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.