From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 02 Dec 2016 14:11:23 -0600 Message-ID: <878trydrbo.fsf@red-bean.com> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> <83bmwuogfb.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1480709510 29786 195.159.176.226 (2 Dec 2016 20:11:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 20:11:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 21:11:45 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCuBK-0005IS-62 for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 21:11:42 +0100 Original-Received: from localhost ([::1]:36325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCuBJ-0001vk-7Y for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 15:11:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCuB9-0001vc-Bg for emacs-devel@gnu.org; Fri, 02 Dec 2016 15:11:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCuB5-00062C-VX for emacs-devel@gnu.org; Fri, 02 Dec 2016 15:11:31 -0500 Original-Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]:36450) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCuB5-00061t-Kh for emacs-devel@gnu.org; Fri, 02 Dec 2016 15:11:27 -0500 Original-Received: by mail-io0-x22a.google.com with SMTP id m5so363451268ioe.3 for ; Fri, 02 Dec 2016 12:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=EMBNWszyPw8Hx37aSGEyZPmbme7eJl29RBpUCsYv5UQ=; b=uRf+XFW4KPsWZUO+Ba8maW87DR5Vbi7pEi+8YsqNUtjsZSMPwfxqaWATP1e1bWmlC/ vhkPbOJY6QbzxiUibbm68nQdMzqmFiKtFqvLv0mLwk4rJgPEsBw71BHbPqxwfJUFshq4 Q2lV/RoAg5wUwzGYwmSSdH1tCh5w+hiAKSJA571/Gyjys9ejbpl3S3no7SXzU1q417kb +PnXdP8DWTgTPyBXO7MkKxP+wlfgLBux72nWcxza+jTj4b/FaeTgPjJs7ipUOeCevgNP yEquGNOpVmqKckCCKjY+h+EBUGZfP+LAYE7WoyHLhdcFEKVJPLuU9tLTbaXWwT7kfR8h jQEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:references:reply-to:date :in-reply-to:message-id:user-agent:mime-version; bh=EMBNWszyPw8Hx37aSGEyZPmbme7eJl29RBpUCsYv5UQ=; b=IRFpLYMyFL8LFWS2/CHT0QN5e0dDZFeeGDOQsRsFjVIhKrnTfZH/afalzfQz2CBF5p i5A7zODoJ1J3zP+95SmI5VxHRQf/WRn0Y92yF/8e7gUre5yMqqMhuanp0mVovBPo4edV l6H7Qr2GcSdgXRLkMdWWiYtc/WT0vGruDhPGTmGmQWrgnH+SZWDzOyTo5WuVxrnGX711 l9g63hIkK0YOWuID1dCoILDNxPwk9Va4kkbEhOpVQGmoYbC01GWRT3TFhToZskmj+Pmp J30ToYSKgesBKDkNTX4HQTJQ9GktqZcufqqWs0nC9JP5w3twEyn7rbC5dWHjQV3Hrdg3 0CZg== X-Gm-Message-State: AKaTC00TnWqbwffRAqyyXASqJn82e1bCm9FyhCDOe2Hvwq0/gBkwh7bAJiIzn0Zg6Bt26w== X-Received: by 10.107.174.142 with SMTP id n14mr39199555ioo.205.1480709485363; Fri, 02 Dec 2016 12:11:25 -0800 (PST) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id 78sm1606710itm.19.2016.12.02.12.11.24 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Dec 2016 12:11:24 -0800 (PST) In-Reply-To: (John Wiegley's message of "Fri, 02 Dec 2016 11:39:57 -0800") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c06::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209942 Archived-At: --=-=-= Content-Type: text/plain 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 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEsgfAWXyjn8Fyi3xbCKC3XMXtg0UFAlhB1WsACgkQCKC3XMXt g0WMHRAAwcy+1DKuYUQEJkvjAjBhYaEVChqb1YO0D6zmlQ2NPewGbRPSdT1w/7+d wyqHFSewQlTXLruhloLVB6VJPmPWT2F3Cn3P5Jx5rRYzrJW7C5qEWR7/7M35KYm2 VKcGC89gS5WBGDBzbplg/81q2JhevRt+x4JxFHtbUmom7WWYnzwnXSHz/25r6KKT 7Ism5NIujKRMFMJVi4tPG9EvXyQ9eV3TIDqF5INpGWpgAx/iYzXRqRpQUp3ZTqtY 9w5yF/WuUjjvgT3hi4fcf6tCV4eW3A0eNNEROOZBbsqtcCdM9TnSPSZNGW2xSM1c mPa8U1XXHbuaTCtcp/UJHK5ZhZv4OgQdPWAdl3bmjrxqff/+dI8TXq2GcSY6gvMU Qkh+tEjPDi4xhNfjo6JcD8t/9kkzZreZqIjpwfFieVLerLRRSYKfzu2py3ZnxEl2 KfkY8MF/Jedhm7epNENAc+aOtkkU5FS8yc/keQEuM0cQ05VeKvKFIZz1w66Xmm6X tdOzB64jm2W3azQt4sAg2b5XZ1mGn07i1h1oTXlBc5vu8GnSDUfmq7swWsDzWowo 4C4NuumVWayBRx1muJ3bVQtasHQzLyamo8jsJ6iDNNMlp5T43AylL9Rr72Z3juBI LWIDJJOjQ+rcu/SSRPaFlpKwAkrjlmOWyADl8zU2uJADoyfzd7Q= =x5oD -----END PGP SIGNATURE----- --=-=-=--