From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [BUG] ob-sql.el: probably an extra paren Date: Thu, 21 Mar 2013 18:38:24 +0100 Message-ID: References: <16047.1363748067@alphaville> <86vc8mtfcx.fsf@somewhere.org> <87fvzqnpfd.fsf@bzg.ath.cx> <87fvzozx88.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:44293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIjRe-0002bK-VY for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 13:38:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIjRc-0008Mu-Tx for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 13:38:30 -0400 Received: from plane.gmane.org ([80.91.229.3]:34545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIjRc-0008Ml-Ne for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 13:38:28 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UIjRx-0001gR-69 for emacs-orgmode@gnu.org; Thu, 21 Mar 2013 18:38:49 +0100 Received: from p578f169c.dip.t-dialin.net ([87.143.22.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Mar 2013 18:38:49 +0100 Received: from Stromeko by p578f169c.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Mar 2013 18:38:49 +0100 In-Reply-To: <87fvzozx88.fsf@bzg.ath.cx> 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: emacs-orgmode@gnu.org Am 21.03.2013 14:41, schrieb Bastien: > The test are not automatic, they are manually triggered, so we don't > have an "automated tests framework" -- or am I misunderstanding what > an automated test framework is? What you probably have in mind is a continuous integration framework that triggers the test framework. > This I 100% agree with. I don't push commits that are known to me as > not passing the tests :) The cavalier attitude is not funny, smiley or not. > It is about life being short and time being spent on testing vs > coding. No, this is about doing it right or doing it twice. I have a fairly slow machine, but running "make test" or even "make test-dirty" with all tests enabled has not consumed an appreciable amount of my lifetime and probably never will. It has however saved me some pushes that had incomplete commits or some "obviously safe" last minute changes that turned out not to be or triggered some unexpected behaviour someplace else. I have also spent a good deal of time weeding out false positives from bisects that could have been automated if one could assume that each commit was always passing its tests. > If you can come up with a pre-push hook that is clever enough to > distinguish trivial-and-safe changes against those who need to be > tested, please submit one. A trivial-and-safe change is either: > > - a change against non-code files; > - a change in docstring. > > I don't think this is easy to do. It is also a waste of time and not necessary. Simply run the tests on each commit touching lisp/ and testing/ and reject the data from the push if any test fails. Not sure if Jason wants to put this on the server, though. Regards, -- Achim. (on the road :-)