From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [Bug] commit 39070b7fc7 breaks babel test Date: Fri, 06 Dec 2013 19:31:10 -0700 Message-ID: <87txel2xyl.fsf@gmail.com> References: <87eh622s3g.fsf@Rainer.invalid> <87ob4t6b3q.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vp7hJ-0003v5-CV for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 21:32:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vp7hC-0000j3-QK for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 21:32:49 -0500 Received: from mail-pb0-x232.google.com ([2607:f8b0:400e:c01::232]:55569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vp7hC-0000iz-Hn for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 21:32:42 -0500 Received: by mail-pb0-f50.google.com with SMTP id rr13so2124078pbb.9 for ; Fri, 06 Dec 2013 18:32:41 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Skip Collins Cc: Achim Gratz , emacs-org list Skip Collins writes: > On Fri, Dec 6, 2013 at 2:05 PM, Eric Schulte wrote: >> Skip Collins writes: >>> Would it make sense to automatically enforce passing all tests before >>> git accepts a change? >> >> I for one would strongly oppose this change. This would only make it >> take longer and thus make it less likely that new code is committed. >> This is the master branch where development should be fast and >> experimentation should take place, not the maintenance branch. > > Designating something as an expected failure seems to be a good way to > track minor issues that need eventually to be resolved. As a user, I > frequently update with make up2 just to avoid getting bitten by stupid > errors that might sneak into master. Is it really that much extra work > for a developer to run the same command before committing and either > fix the error or mark it as a known failure? If it increases the time taken to make a change by say 25%, then it will result in me addressing only 4/5 as many issues. I personally favor 1. a flexible master branch where we can try things out and spur discussion 2. a setup with less hurdles to committing---it's easy to revert a commit, but impossible recover a commit which is never made Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D