Re: Preview: portable dumper

[Karl Fogel]

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.

signature.asc
Description: PGP signature