emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preview: portable dumper


From: John Wiegley
Subject: Re: Preview: portable dumper
Date: Fri, 02 Dec 2016 11:39:57 -0800
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (darwin)

>>>>> Eli Zaretskii <address@hidden> writes:

> But with all due respect, you cannot have it both ways: beg me to stay in
> charge, and then push me to give up one of the few firm ideas I have about
> where Emacs should go and how.

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.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]