Skip Collins <skip.coll...@gmail.com> writes: > On Fri, Dec 6, 2013 at 2:05 PM, Eric Schulte <schulte.e...@gmail.com> wrote: >> Skip Collins <skip.coll...@gmail.com> 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
