+1
> On 16 Aug 2017, at 15:55, Paul Davis <paul.joseph.da...@gmail.com> wrote:
>
> On Wed, Aug 16, 2017 at 1:46 AM, Joan Touzet <woh...@apache.org> wrote:
>> Hi committers,
>>
>> I'd like to propose a change to our policy on version control, namely
>> that no check-ins be allowed on the master branch unless CI test runs
>> against that PR are clean.
>>
>> We've worked hard as a group to get runs clean. We need to protect
>> that achievement and investment in our test suite. That means not
>> letting rogue check-ins slip by because we are ignoring a red X in
>> GitHub (GH) from the Travis run.
>>
>> Things I see as exceptions:
>> * Changes to things clearly not related to the test suite, i.e.
>> documentation, support scripts, rel/overlay/etc/ files, etc.
>> * Changes already agreed upon in a previous PR/discussion for
>> administrative tasks
>>
>
> I'd be +1 for requiring a clean Travis-CI run before something can be
> merged. I'm pretty sure we can configure that easily enough (via INFRA
> as you mention). However I'd make that absolutely no exceptions. I'd
> also disable commits directly to master not coming through PR so that
> it can't be bypassed. This is especially important for when merge PRs
> to dependencies we'd need to require the rebar.config.script update to
> PR'ed so it goes through CI.
>
>> Interesting situation right now for a discussion: Garren has a PR up[1]
>> that enables the mango tests to be part of the standard Travis/Jenkins
>> runs. Unfortunately, it doesn't pass on one of our platforms right now
>> and that needs investigation. Should we allow the PR to land and fix
>> the problems in master, or should the PR hold-up until it can land along
>> with the fixes for the failing mango tests? I can see both sides of this
>> argument.
>>
>> It may or may not be possible for our GH setup to actually prevent such
>> checkins (the Apache GH setup is somewhat restricted, and various things
>> like commit hooks and webhooks have to be configured by INFRA, not us).
>>
>> I'd like to further discuss whether people feel such a hook would be
>> acceptable, onerous or otherwise. Personally, I worry that such a setup
>> might prevent us from checking in some of the exceptions above, but if
>> there is a way around it, we could proceed down that path.
>>
>
> I don't think we should entertain any gray area as it muddies the
> waters. I'd say we either make it 100% or leave it in the current
> state of "best effort" which is what I believe your current example
> falls into which is the status quo.
>
>> What do you think, sirs?[2]
>> Joan
>>
>>
>> [1]: https://github.com/apache/couchdb/pull/753
>> [2]: It's a Mystery Science Theatre 3000 Joel reference. :)
