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: Wed, 30 Nov 2016 13:35:57 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <0839b53b-4607-144f-3746-db054a29c1cd@cs.ucla.edu> <83zikiqdu5.fsf@gnu.org> <834m2orkhn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480541781 21284 195.159.176.226 (30 Nov 2016 21:36:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2016 21:36:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Paul Eggert , rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 22:36:15 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 1cCCY2-0004Yq-6Y for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 22:36:14 +0100 Original-Received: from localhost ([::1]:46756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCCY6-0003oE-23 for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 16:36:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCCXv-0003nT-HJ for emacs-devel@gnu.org; Wed, 30 Nov 2016 16:36:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCCXu-0007No-7I for emacs-devel@gnu.org; Wed, 30 Nov 2016 16:36:07 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46118) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCCXt-0007NR-Tg; Wed, 30 Nov 2016 16:36:06 -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=10V23zGRZyuyejjk4BQl8qxPl2lJzb4zKKlyTfHs9q0=; b=SZxb3wAAr7bMuUWqaV+SP7ClXyx0BRmwoeNka4L8Z18eRs6S9Ca1rFZhkJExRADyfymvBzzMhydDjNNOmTjsFsPaJGRe/t5F4q6EAD/XCjsZH1/bYscU/4GFXXexH31YhcleCYGMckWFmU6RkNxLtCXGm3yfDO1yMeB8lHVi74iovH+ScjyE32M7kgue6lE3yTTkGQFOqneS8AeUQWgSVrlYnveZxmCtXzKwSP9704uGqkf5udM7HqEUnEkD8PqTPFEypglHiV39NFTmNvAOk3vjVZosJdLjw1HdK1zc6pHgSmCyqI04eNVThIHGcMhb/NQOc0F1kFMZ5hh8Z3LYpg==; 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 1cCCXs-0000cx-It; Wed, 30 Nov 2016 13:36:04 -0800 In-Reply-To: (John Wiegley's message of "Wed, 30 Nov 2016 13:03:46 -0800") 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:209837 Archived-At: On Wed, Nov 30 2016, John Wiegley wrote: >>>>>> "DC" == Daniel Colascione writes: > > DC> No. This code isn't disruptive to the Emacs core if it's used, so there's > DC> no reason to keep it out of master. Experience with the concurrency branch > DC> tells me that interesting work in some feature branch ghetto never > DC> actually gets merged. > > You've only tested this on one platform so far, yes? That alone is reason not > to merge it immediately into master. Also, I'd like to see documentation > before it goes in, because that's essential to its maintainability. > > Further, I don't like hearing ultimatums, on either side, over what amounts to > an efficiency issue. This matter has already shown that it deserves a little > cooling off and further thought. Call it a ghetto if you will, but you've not > convinced me that incubating code in branches is a bad idea. It's not an ultimatum: I'm merely being up-front about the that work I am willing to do and the work that I am not willing to do. I am not willing to work on this code in a branch, because if I do, it is very likely that this code will never be merged --- just like the concurrency branch. If we put this thing on a branch, it will be ignored. At best, every few years, someone will bring it the portable dumper --- just like the concurrency branch --- and ask why we don't use it. At those times, we'll repeat the same argument we're having now and and never move forward with merging the increasingly bitrotted code. What will change in the future, when we talk about merging the hypothetical branch? Nobody has expressed concern about the technical quality of this feature. Yes, of course the final version will have more documentation --- but that's something we can do right now, pre-commit, not something we need to incubate on a branch. It's not as if we think this thing might destabilize Emacs, especially if (at first) it's not actually compiled into Emacs by default. Putting this code on a branch is burying it. Do you want to reject code that *exists* and that solves real problems on the basis of one developer's philosophical objections and preference for code that does not exist, that nobody has signed up to write, and that I insist will never perform adequately? How disappointed do you want to make people who've written working code that solves real problems?