On 16 January 2013 08:35, Nathaniel Smith <[email protected]> wrote: > When this has come up on the numfocus list before the status was, sure, > they can provide resources/funding if you can find someone to do the actual > work :-). If anyone is interested in putting in the time to solve this > problem properly then a lot of projects would be grateful I think...
We'd certainly be interested in a better solution for IPython - I think we see more Travis builds failing because of Travis than because of the actual code. Before Travis started testing pull requests, we wrote our own test_pr.py script [1], which fetches a PR, merges it into master, tests on several versions of Python, and (optionally) posts a comment to Github with the results. This should be pretty easy to adapt to other projects - NetworkX already decide to use it [2]. With a little more code, I imagine we could configure a server to regularly scan pull requests for changes and test them. Sympy also have a system for automatically testing pull requests [3]. I think this is somewhat more advanced, with a queue on Google Appengine, and workers which pull jobs from the queue. Finally, we're keen users of ShiningPanda [4]. It doesn't test pull requests, but it's reliable, and can handle things like coverage metrics nicely. [1] https://github.com/ipython/ipython/blob/master/tools/test_pr.py [2] https://github.com/networkx/networkx/pull/752 [3] http://reviews.sympy.org/ [4] https://jenkins.shiningpanda.com/ipython/ Best wishes, Thomas
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
