Re: Protecting master branch on GitHub?

On 2017-08-24 12:34, Peter Cock wrote:
> On Wed, Nov 11, 2015 at 5:19 PM, Peter Cock <[email protected]> wrote:
>> On Fri, Sep 4, 2015 at 11:20 AM, Peter Cock <[email protected]> wrote:
>>> On Fri, Sep 4, 2015 at 10:07 AM, Christian Brueffer
>>> <[email protected]> wrote:
>>>> On 2015-09-04 11:02, Peter Cock wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> GitHub have rolled out some interesting new functionality:
>>>>> https://github.com/blog/2051-protected-branches-and-required-status-checks
>>>>>
>>>>> The ability to protect the main branch should prevent any accidental
>>>>> rewriting of the history (from a forced push), which would cause
>>>>> widespread inconvenience now we have so many forks. I'd like to
>>>>> enable this if no one objects.
> 
> We turned this on in November 2015.
> 
>>>>> The second new feature would disable the web-GUI merge button
>>>>> until our TravisCI tests have passed. I usually do the merges at
>>>>> the command line anyway (sometimes rebasing, often to add a
>>>>> note to the NEWS and CONTRIB files), but again these seems like
>>>>> a sensible precaution? What do people think?
>>
>> ...
>>
>> Right now I have not enabled this higher level of protection, the
>> text for which reads:
>>
>> "Require status checks to pass before merging.
>> Choose which status checks must pass before branches can be
>> merged into master. When enabled, commits must first be pushed
>> to another branch, then merged or pushed directly to master after
>> status checks have passed."
> 
> Many times we as a group have broken the builds on the master
> branch (TravisCI and/or AppVeyor tests were failing). This can
> cause work for each other, but worse it causes false-positives for
> testing pull requests which may deter new contributors.
> 
> If anyone can push directly to the master branch this is all too
> easy to do, even a "harmless" edit can sometimes surprise us
> (e.g. fails a style check, or impacts a doctest), and I'm guilty of
> this too.
> 
> How do people feel about changing our policy to say changes
> should all happen via pull requests (and take advantage of the
> GitHub settings to enforce this)?
> 

+1 from me, seems like a good idea.

Chris