[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [Bug] commit 39070b7fc7 breaks babel test
From: |
Eric Schulte |
Subject: |
Re: [O] [Bug] commit 39070b7fc7 breaks babel test |
Date: |
Fri, 06 Dec 2013 19:31:10 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Skip Collins <address@hidden> writes:
> On Fri, Dec 6, 2013 at 2:05 PM, Eric Schulte <address@hidden> wrote:
>> Skip Collins <address@hidden> 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