From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Thu, 01 Dec 2016 05:47:21 +0200 Message-ID: <83h96opaye.fsf@gnu.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480564059 479 195.159.176.226 (1 Dec 2016 03:47:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 03:47:39 +0000 (UTC) Cc: eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 01 04:47:33 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 1cCILM-0007QO-OM for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 04:47:32 +0100 Original-Received: from localhost ([::1]:47911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCILQ-0004hF-9Z for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 22:47:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCILK-0004gy-1W for emacs-devel@gnu.org; Wed, 30 Nov 2016 22:47:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCILG-0005jV-46 for emacs-devel@gnu.org; Wed, 30 Nov 2016 22:47:30 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCILG-0005jO-0X; Wed, 30 Nov 2016 22:47:26 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3142 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cCIL5-00040z-JK; Wed, 30 Nov 2016 22:47:16 -0500 In-reply-to: (message from Daniel Colascione on Wed, 30 Nov 2016 13:50:33 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209858 Archived-At: > 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. 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. 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". In this case, we will probably also consider alternative approaches if they become mature. > 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. It was disabled post-factum, when we have learned about those problems, unfortunately after its developer has departed. > Branches are for experimental features that can't coexist with > regular Emacs use and development. This is simply not true.