[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preview: portable dumper
From: |
Karl Fogel |
Subject: |
Re: Preview: portable dumper |
Date: |
Fri, 02 Dec 2016 14:11:23 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
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
- Re: Preview: portable dumper, (continued)
- Re: Preview: portable dumper, Richard Stallman, 2016/12/01
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/01
- Re: Preview: portable dumper, Stefan Monnier, 2016/12/01
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/02
- Re: Preview: portable dumper, John Wiegley, 2016/12/02
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/02
- Re: Preview: portable dumper, John Wiegley, 2016/12/02
- Re: Preview: portable dumper,
Karl Fogel <=
- Re: Preview: portable dumper, Daniel Colascione, 2016/12/02
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/02
- Re: Preview: portable dumper, Karl Fogel, 2016/12/02
- Re: Preview: portable dumper, Philippe Vaucher, 2016/12/15
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/02
- Re: Preview: portable dumper, Daniel Colascione, 2016/12/02
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/03
- Re: Preview: portable dumper, Daniel Colascione, 2016/12/03
- Re: Preview: portable dumper, Eli Zaretskii, 2016/12/03
- Re: Preview: portable dumper, Alan Mackenzie, 2016/12/03