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 17:15:49 -0600 Message-ID: <87eg1pdisa.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> <878trydrbo.fsf@red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480720569 11791 195.159.176.226 (2 Dec 2016 23:16:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 23:16:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 00:16:05 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 1cCx3h-0001kX-A9 for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 00:16:01 +0100 Original-Received: from localhost ([::1]:36929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCx3l-00045F-34 for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 18:16:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCx3c-000457-1K for emacs-devel@gnu.org; Fri, 02 Dec 2016 18:15:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCx3Y-0004p6-Pj for emacs-devel@gnu.org; Fri, 02 Dec 2016 18:15:56 -0500 Original-Received: from mail-io0-x231.google.com ([2607:f8b0:4001:c06::231]:35878) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCx3Y-0004ow-FZ for emacs-devel@gnu.org; Fri, 02 Dec 2016 18:15:52 -0500 Original-Received: by mail-io0-x231.google.com with SMTP id m5so370674002ioe.3 for ; Fri, 02 Dec 2016 15:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=GmSVXSCzwEahoBQAVqtoEUEzVj2vdCtfqPKex2ttqF4=; b=xIwFC30peGi4crZ2TQGjJhKclGyvofJ23LazL3Ynx9Vtd9hwRrImjsKmpMDcy+eCLQ 3D/unhBNuEnxpeMep+r14Bp24Q88RcBitawHEIO/sH+dG69PBzxS896bzeMBnCK/Ggoz G0mmHO/3RWfQ0H6ZhMSNlP+o+v7hxHd2eNurV4v5LNYe/ydFJZfewS9ZTNE2Zuh1ipui +fh1CzXilosfhEWlPdWAKfOdrF8xeKNujtH+L2ZSour0UjZuIyvj3Bt4nc0N5h3PdP8Q Nj5dGrMT5ri8EBmG2zbepWSTQyR4gX60TGu/WxySerwTGxHvU1ApgbopN5AK4dmy9prq 2Jzg== 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:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=GmSVXSCzwEahoBQAVqtoEUEzVj2vdCtfqPKex2ttqF4=; b=DIlYEVPvJyKBQFkuBynwBM2FjTslxUNq21/hjNanXXHA5k49Y3n+xe9tukL2gk5lHF 2EJPhNGTgaKX7sRUjFnPjXtgoEPrQG11upiZhXZObmnAxKkeNsGSStr1i17rjN6nAOFb 42nZjLskhKcCJDWwf8dYg4oD6dB1D2PEUjiA6ay4erNwVrMARetGiKBaIrhF+TeKGj3j EAks/Q4/yktGHTGX4MQ/cUhV/sIT4zuEAqG4ErJ2mJMTtcaviDPd/Hv0b454VA7ads60 LNYrYz8DyRyOyretdx9obt3mooHigNRBuFpG0AlAc09zOcIJ46+a9KjK4vjvaV6cF8JV jmPg== X-Gm-Message-State: AKaTC00LWlvWxZ3YARNOO787AFqJrx1nuQRgOGJEw4c7hfGlu19SVSiiZeFMmutUMcsB6w== X-Received: by 10.107.47.26 with SMTP id j26mr38060076ioo.85.1480720551082; Fri, 02 Dec 2016 15:15:51 -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 l203sm1880469ita.6.2016.12.02.15.15.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Dec 2016 15:15:50 -0800 (PST) In-Reply-To: (Daniel Colascione's message of "Fri, 02 Dec 2016 13:22:56 -0800") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c06::231 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:209955 Archived-At: Daniel Colascione 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 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.