On Thu, 24 Mar 2011 08:46:37 -0400 Tres Seaver <tsea...@palladion.com> wrote: > > > > > That doesn't work so well at a sprint, where the point is to maximize > > > the value of precious face-time to get stuff done *now*. > > > > That's where the D in DVCS comes in. It's a new world, friends. All > > you need to do is bring a $50 wireless router to the sprint, and have > > some volunteer set up a shared repo for the sprinters. Then some > > volunteer *later* runs the tests and pilots the patches into the > > public repo. Where's the latency? > > The current full test suite is punishingly expensive to run, sprint or > not. Because of that fact, people will defer running it, and sometimes > forget. Trying to require that people run it repeatedly during a push > race is just Canute lashing the waves.
Punishingly expensive? You have to remember that Python is an entire programming language with its standard library, used by millions of people. That its test suite can run on 4 minutes on a modern computer actually makes it rather "fast" IMO (and, perhaps, incomplete...). If you have a "push race", then after merging you could just re-run the tests that are affected by your changes (of course, if you did a change in the interpreter core, you probably should run the whole suite again). That's both faster and better focussed than a hypothetical "smoke test". (that assumes you did run the test suite before doing the original commit, of course) Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
