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 20:10:42 -0800 Message-ID: <1A0196FE-EF1E-4ECF-B0DF-A3893EE864C5@dancol.org> 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> <83h96opaye.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1480565637 4637 195.159.176.226 (1 Dec 2016 04:13:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 04:13:57 +0000 (UTC) User-Agent: K-9 Mail for Android Cc: eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 01 05:13:52 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 1cCIkn-0008CI-9P for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 05:13:49 +0100 Original-Received: from localhost ([::1]:48014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCIkr-0007Gi-0Z for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 23:13:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCIkg-0007FS-RQ for emacs-devel@gnu.org; Wed, 30 Nov 2016 23:13:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCIkf-0001DT-Qf for emacs-devel@gnu.org; Wed, 30 Nov 2016 23:13:42 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:51012) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCIkc-0001Ao-Cx; Wed, 30 Nov 2016 23:13:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-ID:CC:To:Date:From:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To; bh=s9ei5yXiili13ubyPUxpmUkzrtbAxjPdCFIkuGnCiu4=; b=qWwIux83qyl2aAao6zZqrx1KvcEWRL+tJd+CXRfqGO2ivPx8tEwix59XRD8E2pPzJWRaethgUfxTzzTYPyy5Ea9oNazrBN95xaLrjsRTw6liQ/i+h5G+VAnDP9PVrBW4wdRUcnzpP4/Cc5KRlVQLWs0NgNj78eC3nsFQ6umZpRGhLAuMFLWZbW+aSpurL4eQAIiez7sAw1Z56NbcajzoP7G8fmCUPF5sVvSAIyF5KXCXDzxpQZ2HY+h/zTPrNfYvih5/4sFoU5+PZFaotzvVexdsosNIHAr9v1io5G/9HYuiMZ9YKa5GP5tdtVPS2RU7k/0muoVBS4PyWFgN46G/xw==; Original-Received: from [166.170.39.160] (helo=[10.204.89.253]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cCIkb-0004J3-AU; Wed, 30 Nov 2016 20:13:37 -0800 In-Reply-To: <83h96opaye.fsf@gnu.org> 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:209861 Archived-At: On November 30, 2016 7:47:21 PM PST, Eli Zaretskii wrote: >> From: Daniel Colascione >> Cc: Paul Eggert , rms@gnu.org, >emacs-devel@gnu.org >> Date: Wed, 30 Nov 2016 13:50:33 -0800 >> >> > Until you're code is tested on more platforms, it needs to live >someplace >> > other than master. That's what branches are for. >> >> I'll test it on the systems I can before I commit. We can enable >> compilation once on individual systems once we do more thorough >testing. >> A branch is definitely not the right approach here, because you >haven't >> established any firm acceptance criteria, and what criteria you have >> mentioned (write some documentation, test on more configurations) are >> things I can do before the patch lands at all. > >Having new features on a branch is our standard development practice. No it isn't. >It allows the interested people to try the feature in situations no >single person can possibly create, even if that person has access to >several platforms, because usage patterns differ a lot. No, that's what configuration options do. Branches are seldom touched, because there are much bigger barriers to trying them. >We can establish pass criteria, if you like, but the only criteria >until now were "if enough time passed and no one complained, it's >ready". You have wanted to kill this feature at any cost, contrary to the wishes of every other Emacs contributor. What kind of fair pass criteria can I expect? >In this case, we will probably also consider alternative approaches if >they become mature. Got it. So we won't consider merging the code until some lread improvement comes along somehow (which might take years) and we'll declare the lread improvement the winner no matter what the performance difference. >> The Cairo code doesn't work at all and *that's* in mainline. >> That's okay, because it's not enabled by default. > >The Cairo code works, it just has some redisplay bugs that no one was >able to fix. So it doesn't work. > It was disabled post-factum, when we have learned about >those problems, unfortunately after its developer has departed. It's obvious within five minutes of trying the feature that it doesn't work. That's okay, because it's opt-in. >> Branches are for experimental features that can't coexist with >> regular Emacs use and development. > >This is simply not true. It is true if you look at the history of things for which we've actually used branches. Putting this feature on a branch is tantamount to killing it. There is no legitimate reason to keep it out of mainline, because it is harmless unless enabled, and we can keep it disabled for the moment.