Re: Preview: portable dumper

[Daniel Colascione]

On Wed, Nov 30 2016, John Wiegley wrote:
>>>>>> "DC" == Daniel Colascione <address@hidden> writes:
>
> DC> It's not an ultimatum: I'm merely being up-front about the that work I am
> DC> willing to do and the work that I am not willing to do. I am not willing
> DC> to work on this code in a branch, because if I do, it is very likely that
> DC> this code will never be merged --- just like the concurrency branch.
>
> BTW, the concurrency branch has the green light. If anyone is willing to work
> to resolve its remaining issues, they can merge it to master once ready.
>
> DC> Putting this code on a branch is burying it. Do you want to reject code
> DC> that *exists* and that solves real problems on the basis of one
> DC> developer's philosophical objections and preference for code that does not
> DC> exist, that nobody has signed up to write, and that I insist will never
> DC> perform adequately? How disappointed do you want to make people who've
> DC> written working code that solves real problems?
>
> Until you're code is tested on more platforms, it needs to live someplace
> other than master. That's what branches are for.

I'll test it on the systems I can before I commit.  We can enable
compilation once on individual systems once we do more thorough testing.
A branch is definitely not the right approach here, because you haven't
established any firm acceptance criteria, and what criteria you have
mentioned (write some documentation, test on more configurations) are
things I can do before the patch lands at all.

The Cairo code doesn't work at all and *that's* in mainline.
That's okay, because it's not enabled by default.  Branches are for
experimental features that can't coexist with regular Emacs use
and development.  The portable dumper is not such a feature.