From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 02 Dec 2016 13:22:56 -0800 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480714111 22896 195.159.176.226 (2 Dec 2016 21:28:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 21:28:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 22:28:28 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 1cCvNZ-0005Dz-O6 for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 22:28:26 +0100 Original-Received: from localhost ([::1]:36530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCvNd-0004dp-HE for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 16:28:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCvIQ-0008Sd-8U for emacs-devel@gnu.org; Fri, 02 Dec 2016 16:23:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCvIO-0004kv-W6 for emacs-devel@gnu.org; Fri, 02 Dec 2016 16:23:06 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:53368) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCvIO-0004kf-MU for emacs-devel@gnu.org; Fri, 02 Dec 2016 16:23:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=C1ExkGruHtrUgqB0XUi+Rosg3+cXjkNrk4dwk8JYCdk=; b=OItcTMUMxwarghEYTH7TBqzYJXxi+0KXLQiVCzgForfVLmyF2rFCTF11UI2ARM47FtBMSszMMmnnWGzoPEk23hvTl3K9HC5N2hpqBdD3BsT4RO0c8qbOYG2/6S4LTvZZvSYY8omTIW43GYpPgys6b7D9wbNoxLyckkQmDuZ2jYAF1hyyj3v+m6FmIeLawDMGWUL/+iM4sLksMTE+0iYHrtDHSUCXMNcxBT8K39aT4Q7GRNLKE5l4rhYnF+I3JNXspEsl3zPm2SIMIblFdi8ezFTdZSOhlJzjn0KXEE4xIgaxw2lwB5sioBWPkEvYJaW2hiy3Qlgp90J/XQVvLXD3iA==; Original-Received: from [2620:0:1008:100b:bc8e:4940:ab86:ab74] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cCvIN-0002Uo-7t; Fri, 02 Dec 2016 13:23:03 -0800 In-Reply-To: <878trydrbo.fsf@red-bean.com> (Karl Fogel's message of "Fri, 02 Dec 2016 14:11:23 -0600") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209944 Archived-At: FWIW, I'll put my patch on a branch this weekend. 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.