Re: [Bug] commit 39070b7fc7 breaks babel test

[Eric Schulte <schulte.eric@gmail.com>]

Skip Collins <skip.collins@gmail.com> writes:

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