Re: Preview: portable dumper

[Daniel Colascione]

FWIW, I'll put my patch on a branch this weekend.

On Fri, Dec 02 2016, Karl Fogel wrote:
> Following up to what John said, with a perspective that may be useful to Eli:
>
> Eli, I have a great deal of respect for your technical judgement and
> the amount of work you put into Emacs.  But I have a slightly
> different take on what maintainership means.
>
> When I was in a position similar to yours (one of a small group of
> core co-maintainers, in the Subversion project), there were a few
> occasions when a major technical decision went in a direction I didn't
> agree with.  My disagreement was not of the "this will destroy the
> project" sort, but I did feel the decisions were poor technical
> choices that could be a long-term drag on the project -- creating
> extra maintenance work for existing developers, and creating barriers
> to entry for new developers.  In other words, objections very similar
> to yours now.
>
> In each case, discussions eventually made it clear to me that my
> opinion was not going to prevail.  There were just too many developers
> who felt differently.  This didn't tempt me to step down from
> maintainership, though I will admit that it *did* tempt me to keep
> score a bit, so that later on I might be able to say "Hey folks,
> remember when I turned out to be right about X, and Y, and Z?
> So please listen to me this time."  I think I may even have used that
> privilege once or twice later :-), though I don't remember clearly if
> I did.  What I do remember clearly is that I turned out to be wrong in
> at least one of the cases (at least, I established to my own
> satisfaction that my warnings had been unwarranted).
>
> Your value as a maintainer is not lessened if a particular decision
> doesn't go the way you recommended.  (Of course, if maintainership
> becomes unenjoyable to you because of the decision, that's a different
> question, and only you can make that call.)  I think there is even a
> good argument that your continued maintainership actually becomes
> slightly *more* important to the project: of all the people who could
> spot whether the negative consequences of the decision are coming
> true, you would perhaps be the person most likely to spot it, and most
> likely to point it out to the other developers.
>
> You must make your own decision, of course.  But I hope this
> perspective is a useful response to your question:
>
>   "...What kind of maintainer will I be if I cannot base my judgment and
>   decisions on a few principal ideas I have about Emacs development?
>   What could replace those ideas to be the base for decisions I need to
>   make almost every day?"
>
> (I pretty much agree with everything John said in his email below,
> too, for what it's worth.)
>
> Best regards,
> -Karl
>
> John Wiegley <address@hidden> writes:
>>I think a part of this job is always political: Balancing the twin goals of
>>promoting the best ideas, while also keeping everyone involved encouraged and
>>motivated. When we say "yes" to an idea, we might be hurting Emacs; but when
>>we say "no", we might be hurting that contributor, and losing their future
>>involvement. Sometimes that's fine -- after all, everyone else in the world
>>wants us to care about Emacs more than a limited-time set of contributors --
>>but we also cannot thrive without active contributors, so "watering the
>>garden" is part of our task.
>>
>>We all know the portable dumper is not an ideal solution; we even have some
>>notion of what the ideal solution looks like. It's indeed a bit frustrating to
>>knowingly support a technology path that may end up incurring a lot of work,
>>if a much better solution might be just around the corner.
>>
>>However, I ask you to consider the merits of Daniel's proposal from several
>>angles -- angles a regular developer may not care about at all:
>>
>> - If we accept the work, we show to others that *code wins*. That is, if a
>>   problem exists in Emacs, and someone comes to us with actual code, this has
>>   tremendous weight. If this is our position, it encourages others to
>>   experiment, since they'll fear less that after so much work, we might just
>>   say "no" because it's not as good a solution as we'd like.
>>
>> - If we accept the work, it encourages Daniel to play a larger role, to learn
>>   more about the C internals, and likely to contribute even more.
>>
>> - If we accept the work, and a better solution comes along later, we can
>>   revert the change without undue labor.  That is, our end cost is not so
>>   terribly high that we're panting ourselves into a corner.
>>
>> - If we accept the work, despite our disagreement, *precisely because most of
>>   the other core developers do agree*, we're saying that their opinion holds
>>   a lot of weight with us, and this encourages frank and open discussion. If
>>   decisions like this are made by just you or me, against all other
>>   objections, it diminishes the value of this mailing list in others' eyes.
>>   It then seems like we're just making the Emacs we want, and not the Emacs
>>   all of us want.
>>
>>I think there is a "greater good" here, and it is not unduly damaged by
>>letting a short-term solution into the code until a longer-term solution
>>appears. There is much goodwill to be gained, and really not so much harm. On
>>the other hand, rejecting it -- despite the general sense of agreement is has
>>gained -- would cause a much greater social damage, which is far more
>>difficult to undo than one day asking Daniel to revert his work.
>>
>>All that said, if you feel strongly that this proposal hurts Emacs itself, and
>>cannot abide it, I understand. I was hoping we could all win here, but I know
>>that sometimes this isn't realistic. I just hope we can all recognize that
>>this portable dumper idea is not so terribly important: not to fork over, nor
>>to resign from the amazing support you provide.