Re: Preview: portable dumper

[Daniel Colascione]

On Wed, Nov 30 2016, John Wiegley wrote:
>>>>>> "DC" == Daniel Colascione <address@hidden> writes:
>
> DC> No. This code isn't disruptive to the Emacs core if it's used, so there's
> DC> no reason to keep it out of master. Experience with the concurrency branch
> DC> tells me that interesting work in some feature branch ghetto never
> DC> actually gets merged.
>
> You've only tested this on one platform so far, yes? That alone is reason not
> to merge it immediately into master. Also, I'd like to see documentation
> before it goes in, because that's essential to its maintainability.
>
> Further, I don't like hearing ultimatums, on either side, over what amounts to
> an efficiency issue. This matter has already shown that it deserves a little
> cooling off and further thought. Call it a ghetto if you will, but you've not
> convinced me that incubating code in branches is a bad idea.

It's not an ultimatum: I'm merely being up-front about the that work I
am willing to do and the work that I am not willing to do. I am not
willing to work on this code in a branch, because if I do, it is very
likely that this code will never be merged --- just like the concurrency
branch.  If we put this thing on a branch, it will be ignored.  At best,
every few years, someone will bring it the portable dumper --- just like
the concurrency branch --- and ask why we don't use it.  At those times,
we'll repeat the same argument we're having now and and never move
forward with merging the increasingly bitrotted code.

What will change in the future, when we talk about merging the
hypothetical branch?  Nobody has expressed concern about the technical
quality of this feature. Yes, of course the final version will have more
documentation --- but that's something we can do right now, pre-commit,
not something we need to incubate on a branch.  It's not as if we think
this thing might destabilize Emacs, especially if (at first) it's not
actually compiled into Emacs by default.

Putting this code on a branch is burying it.  Do you want to reject code
that *exists* and that solves real problems on the basis of one
developer's philosophical objections and preference for code that does
not exist, that nobody has signed up to write, and that I insist will
never perform adequately?  How disappointed do you want to make people
who've written working code that solves real problems?