Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi, Achim Gratz strom...@nexgo.de writes: Hudson. However, I don't think that a CI framework is what we need or want. As I said, simply running the tests (preferrably with two different versions of Emacs) should be enough for now. Unless we hear from Jason if he thinks the server can take the extra load its a moot point to discuss details, but I think this can be done in one of the Git hooks (much like Worg triggers publishing). Yagnesh Raghava Yakkala h...@yagnesh.org writes: About hudson/jenkins (any other CI), If we have resources on the server, I would say we should go for it. That will remove Bastien's concern of slowing down development because of running tests by hand. I'm copying Jason -- the idea is to run tests on the servers via a Git hook, the same way that a Git hook publishes Worg. If the tests fail, the committer would get a warning and the commit would be discarded. Jason, do you think it's feasible? Enough? I guess hudson/travis is really too much for our needs. Thanks, -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
Am 21.03.2013 18:59, schrieb Bastien: Please see my reply to Yagnesh. It clearly describes a situation where automatically running tests with a pre-push hook would be a problem. You keep mentioning a pre-push-hook to be run on the developers machine. However, the test would run on the server and determine whether to accept the commit into the repo or not. All your further arguments seem to be based on that misunderstanding, so I won't comment on them. As for Travis CI: a website that shows absolutely nothing when JavaScript is turned off? No, thanks. Regards, -- Achim. (on the road :-)
Re: [O] [BUG] ob-sql.el: probably an extra paren
Achim Gratz strom...@nexgo.de writes: Am 21.03.2013 18:59, schrieb Bastien: Please see my reply to Yagnesh. It clearly describes a situation where automatically running tests with a pre-push hook would be a problem. You keep mentioning a pre-push-hook to be run on the developers machine. That's what have been proposed by Sébastien: Isn't it possible to put such in some sort of Git pre-commit hook (or pre-push hook), so that it gets automatically enforced? He was replying to Nick who proposed that developers always run make test before pushing. However, the test would run on the server and determine whether to accept the commit into the repo or not. I'm fine with a server-based solution. All your further arguments seem to be based on that misunderstanding, so I won't comment on them. Maybe the server-side solution was so obvious to you that you didn't realize we (Sébastien, Nick, me) were discussing something else. So I'll just assume you agree with my argument against the developer-side pre-push hook then, good. As for Travis CI: a website that shows absolutely nothing when JavaScript is turned off? No, thanks. Do you know any free (as-in-speech), easy-to-use alternative? -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
Am 22.03.2013 08:36, schrieb Bastien: Do you know any free (as-in-speech), easy-to-use alternative? Hudson. However, I don't think that a CI framework is what we need or want. As I said, simply running the tests (preferrably with two different versions of Emacs) should be enough for now. Unless we hear from Jason if he thinks the server can take the extra load its a moot point to discuss details, but I think this can be done in one of the Git hooks (much like Worg triggers publishing). Regards, -- Achim. (on the road :-)
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hello Achim, On Mar 22 2013, Achim Gratz strom...@nexgo.de wrote: As for Travis CI: a website that shows absolutely nothing when JavaScript is turned off? No, thanks. Agreed although travis-ci source is under FSF approved license. About hudson/jenkins (any other CI), If we have resources on the server, I would say we should go for it. That will remove Bastien's concern of slowing down development because of running tests by hand. Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] [BUG] ob-sql.el: probably an extra paren
Am 20.03.2013 14:47, schrieb Bastien: If anyone knows how to setup an automated tests framework for Org, feel free to go ahead, we will use it and monitor broken tests to see what's wrong in the code or in the tests or in the environment running the tests. We already have one, what Nick and Sebastien are asking is not to push commits that are known to not pass the tests. Testing is a nice habit to have, but let's not make it a coercive pre-requisit before pushing patches. Why not? Any broken commits make automatic bisecting impossible and they are a constant source of irritation for folks who forget to test their new Org pulls before using or installing them. My whole thinking here is well captured by Rich Hickey: The citation you gave doesn't even apply to the question at hand. It is about writing tests, not using the tests you already have. Regards, -- Achim. (on the road :-)
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Bastien, Bastien wrote: Sebastien Vauban writes: Nick Dokos wrote: Can we please make it an invariable practice to run `make test' before every push? Isn't it possible to put such in some sort of Git pre-commit hook (or pre-push hook), so that it gets automatically enforced? If anyone knows how to setup an automated tests framework for Org, feel free to go ahead, we will use it and monitor broken tests to see what's wrong in the code or in the tests or in the environment running the tests. Testing is a nice habit to have, but let's not make it a coercive pre-requisit before pushing patches. My whole thinking here is well captured by Rich Hickey: http://codequarterly.com/2011/rich-hickey/ Fogus: You have been known to speak out against test-driven development. Do you mind elaborating on your position? Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. The text you mention refers about time to write extra test suites. I was referring to simply have make test _run_ before being able to push commits. Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Achim, Achim Gratz strom...@nexgo.de writes: If anyone knows how to setup an automated tests framework for Org, feel free to go ahead, we will use it and monitor broken tests to see what's wrong in the code or in the tests or in the environment running the tests. We already have one, 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 Nick and Sebastien are asking is not to push commits that are known to not pass the tests. This I 100% agree with. I don't push commits that are known to me as not passing the tests :) Testing is a nice habit to have, but let's not make it a coercive pre-requisit before pushing patches. Why not? Any broken commits make automatic bisecting impossible and they are a constant source of irritation for folks who forget to test their new Org pulls before using or installing them. My whole thinking here is well captured by Rich Hickey: The citation you gave doesn't even apply to the question at hand. It is about writing tests, not using the tests you already have. It is about life being short and time being spent on testing vs coding. 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. Rich message wrt tests is: Life is short, decide whether you want to spend it on testing or coding -- so I think it's relevant here. I often have only 10 minutes at hand, make a few trivial changes, and push. For me, a mandatory pre-push hook running the test suite would be a useless burden for 50% of my commits. This would irritate me. We might agree to disagree on this. -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
Bastien b...@altern.org writes: I often have only 10 minutes at hand, make a few trivial changes, and push. For me, a mandatory pre-push hook running the test suite would be a useless burden for 50% of my commits. This would irritate me. orgmode.org could run a post-receive hook and report any failure to the committer ? I don't know if orgmode.org can run the testsuite though. -- N.
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hello Bastien, We can use travis-ci for automated tests, I just run tests for org-mode¹ on travis with emacs-snapshot. Magit has been setup recently to run tests for multiple emacs versions² (emacs23, emacs24 and snapshot). travis has a facility to send mails if a test fails. I see you have org-mode repo on your github account, all we need to do put a post recieve hook to mirror org-mode repo to github. we can adopt magit script³ to org-mode as it won't be synced to emacs trunk. what do you think? Thanks., ¹ https://travis-ci.org/yyr/org-mode/builds/5692183 ² https://travis-ci.org/magit/magit ³ https://github.com/magit/magit/blob/master/.travis.yml -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hello Yagnesh, Yagnesh Raghava Yakkala h...@yagnesh.org writes: We can use travis-ci for automated tests, I just run tests for org-mode¹ on travis with emacs-snapshot. Magit has been setup recently to run tests for multiple emacs versions² (emacs23, emacs24 and snapshot). travis has a facility to send mails if a test fails. Great! I see you have org-mode repo on your github account, all we need to do put a post recieve hook to mirror org-mode repo to github. we can adopt magit script³ to org-mode as it won't be synced to emacs trunk. what do you think? I think this would be *fantastic*. I have no time for this at the moment, but anyone willing to help setting this up would be my hero. Really :) This is efficient and not intrusive. To give another argument about why I think a pre-push hook on the developer's side is wrong, imagine this scenario: - developer A pushes a commit, all tests pass - developer B works on latest HEAD assuming all tests pass - he wants to push his commits but the tests fail - he naturally thinks it's a problem with *his* changes - ... but it is not ... - M-x doctor RET This happened for real: recently some tests passed under Emacs 24.3 but failed under Emacs =24.3. If we had a pre-push hook, I would not even be able to push the fix, I would have to deactive the hook first. Best, -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
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 :-)
Re: [O] [BUG] ob-sql.el: probably an extra paren
There is no need to be unpleasant and to describe my attitude as cavalier. Please see my reply to Yagnesh. It clearly describes a situation where automatically running tests with a pre-push hook would be a problem. -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Nick, Nick Dokos nicholas.do...@hp.com writes: Compiling it I get This is fixed, thanks. -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Nick, Nick Dokos wrote: Can we please make it an invariable practice to run `make test' before every push? Isn't it possible to put such in some sort of Git pre-commit hook (or pre-push hook), so that it gets automatically enforced? Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Sébastien, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Nick Dokos wrote: Can we please make it an invariable practice to run `make test' before every push? Isn't it possible to put such in some sort of Git pre-commit hook (or pre-push hook), so that it gets automatically enforced? If anyone knows how to setup an automated tests framework for Org, feel free to go ahead, we will use it and monitor broken tests to see what's wrong in the code or in the tests or in the environment running the tests. Testing is a nice habit to have, but let's not make it a coercive pre-requisit before pushing patches. My whole thinking here is well captured by Rich Hickey: http://codequarterly.com/2011/rich-hickey/ Fogus: You have been known to speak out against test-driven development. Do you mind elaborating on your position? Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. Best, -- Bastien
