Re: Preview: portable dumper

[Eli Zaretskii]

> From: Philippe Vaucher <address@hidden>
> Date: Fri, 2 Dec 2016 10:00:28 +0100
> Cc: Stefan Monnier <address@hidden>, Emacs developers <address@hidden>
> 
>  Once again, if those ideas seem strange, let alone incorrect, to
>  you-all out there, just say the word, and I will step down. Then I
>  can stop worrying about the portable dumper, and you can stop worrying
>  about my strange ideas. Emacs is not my private project; I'm only
>  entitled to promote my ideas if the others either support them or
>  trust me to DTRT. Please decide which one is it, and let's move on.
> 
> Eli, I think you are doing a fantastic job.
> 
> The only problem that seems to happen from time to time is that the 
> discussions starts getting personal and
> ends up with people saying threats like "if you put my code in a branch I 
> will fork Emacs" or "if you don't agree
> with my ideas I will step down", which is just a way of saying "my way or the 
> highway". Using these rethorics
> is not constructive and doesn't do anyone any good.

What do you expect me to do when I see code which takes Emacs in a
direction I think is wrong?  There are a very few of such directions I
feel strongly we shouldn't take.  What am I supposed to do when I see
one of them proposed for inclusion?

More generally, is the maintainer allowed to reject some code or
course of actions?  If yes, what are the criteria for that?

> To Daniel, it's important that his work does not bitrot somewhere like the 
> concurrency branch did. It's also
> important that he feels there's a strong chance of his code getting merged 
> before he works more on it.
> To Eli, it's important to have Daniel's code more "production ready" 
> (documentation, etc), and also to give the
> simpler implementation ideas a try to avoid having to switch/maintain 
> different systems twice in a short period
> of time.

No, you've misunderstood the nature of our disagreement.  There's no
disagreement about the code being production-ready: Daniel himself
said it isn't yet.

> <Eli> Daniel, we'll give other people one month to come up with a sketch of 
> the alternative idea to see if it's
> feasible or not. If nothing comes up after one month, we'll start working on 
> merging your branch.

That's what I said, with the exception of the "month" part.

If we are talking about better communications, then I can suggest
discussing an idea before it is coded.  As a matter of fact, I
proposed a very similar idea 2 months ago, and it was voted down by
Paul, so I didn't pursue it, also because that discussion brought up
the "one large .elc file" idea, which Paul liked better (and so did
I), the only issue with it being the performance that we could get.
If Daniel have described his idea before coding it, I think at least
some of the aggravation (mine included) could have been spared.