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: CC Mode and electric-pair "problem". Date: Tue, 19 Jun 2018 19:59:20 +0300 Message-ID: <83lgbasoev.fsf@gnu.org> References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <8336xkt967.fsf@gnu.org> <83y3fcrqjs.fsf@gnu.org> <83po0nsdr2.fsf@gnu.org> Reply-To: Eli Zaretskii 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 1529427484 15716 195.159.176.226 (19 Jun 2018 16:58:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2018 16:58:04 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org, tino.calancha@gmail.com, rgm@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 19 18:58:00 2018 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 1fVJx6-0003tG-C9 for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2018 18:57:56 +0200 Original-Received: from localhost ([::1]:43911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVJzD-0004wB-NE for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2018 13:00:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVJya-0004vj-PP for emacs-devel@gnu.org; Tue, 19 Jun 2018 12:59:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fVJyZ-0005gX-RX for emacs-devel@gnu.org; Tue, 19 Jun 2018 12:59:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVJyV-0005bb-Lk; Tue, 19 Jun 2018 12:59:23 -0400 Original-Received: from [176.228.60.248] (port=2571 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fVJyU-0006t4-Ex; Tue, 19 Jun 2018 12:59:23 -0400 In-reply-to: (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Tue, 19 Jun 2018 09:13:10 +0100) 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:226521 Archived-At: > From: João Távora > Cc: acm@muc.de, rgm@gnu.org, emacs-devel@gnu.org, tino.calancha@gmail.com > Date: Tue, 19 Jun 2018 09:13:10 +0100 > > >> > But putting the problematic code on a branch reduces the incentive > >> > even more, doesn't it? > >> > >> I don't follow. > > > > Code on a branch gets less testing by others, and therefore less > > reminders about the failing test. > > But surely, the programmer who broke the test, who is the person > technically (and morally) most well suited to fix the problem has the > all the original incentive to merge his work. Of course. But this is not affected by whether the code is on a branch or on master. > For me this is very clear: only merge if there are 0 failing tests (or > rather, if you've increased the number of failing tests by 0). Perhaps > CVS used to make this impractival, but nowadays git branches make this > very easy. That's a good policy. > BTW, why does CONTRIBUTE tell us to "make check" at all? Is this a tricky question? Because I think the answer is clear to all. > >> I would answer "no", assuming the person developing the > >> temporarily misbehaving code is motivated to do it in the first place. > >> Develop and break things at will in a branch, merge them to master when > >> they're clean. No? > > If the code is used, its breakage on a branch hurts like it does on > > master. > > Not at all, no, it hurts only the people interested in trying out the > feature. On master it hurts everyone It hurts those who try the feature on master as well. > including Hydra's continuous integration, for example, which is the > issue at hand. But also other automated things like automated bug > bisections etc... > > > If it's unused, then what is it doing in the repository? > > To save it. To show it to others for comments. This seems rather > obvious to me, so perhaps we are misunderstanding each other. I'm also > pretty sure I've seen branches prescribed in this list for unstable > features. OK, I think it's time to stop this dispute. It isn't going anywhere, and we basically agree on most aspects of this.