Re: Preview: portable dumper

[Daniel Colascione]

On November 30, 2016 7:47:21 PM PST, Eli Zaretskii <address@hidden> wrote:
>> From: Daniel Colascione <address@hidden>
>> Cc: Paul Eggert <address@hidden>,  address@hidden, 
>address@hidden
>> Date: Wed, 30 Nov 2016 13:50:33 -0800
>> 
>> > 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.
>
>Having new features on a branch is our standard development practice.

No it isn't.

>It allows the interested people to try the feature in situations no
>single person can possibly create, even if that person has access to
>several platforms, because usage patterns differ a lot.

No, that's what configuration options do. Branches are seldom touched, because 
there are much bigger barriers to trying them.


>We can establish pass criteria, if you like, but the only criteria
>until now were "if enough time passed and no one complained, it's
>ready".

You have wanted to kill this feature at any cost, contrary to the wishes of 
every other Emacs contributor. What kind of fair pass criteria can I expect?

>In this case, we will probably also consider alternative approaches if
>they become mature.

Got it. So we won't consider merging the code until some lread improvement 
comes along somehow (which might take years) and we'll declare the lread 
improvement the winner no matter what the performance difference.

>> The Cairo code doesn't work at all and *that's* in mainline.
>> That's okay, because it's not enabled by default.
>
>The Cairo code works, it just has some redisplay bugs that no one was
>able to fix.  

So it doesn't work.

> It was disabled post-factum, when we have learned about
>those problems, unfortunately after its developer has departed.

It's obvious within five minutes of trying the feature that it doesn't work. 
That's okay, because it's opt-in.

>> Branches are for experimental features that can't coexist with
>> regular Emacs use and development.
>
>This is simply not true.

It is true if you look at the history of things for which we've actually used 
branches.

Putting this feature on a branch is tantamount to killing it. There is no 
legitimate reason to keep it out of mainline, because it is harmless unless 
enabled, and we can keep it disabled for the moment.