Re: Preview: portable dumper

[Karl Fogel]

Daniel Colascione <address@hidden> writes:
>FWIW, I'll put my patch on a branch this weekend.

Thanks, Daniel.  I will build it and try it out.

Best regards,
-Karl

>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.