A lot of people seems to be confused, so let's clarify the separation of 
roles/responsibilities:

1. The committers that merge code are responsible for code quality and tests 
passing on master.

2. The CI / infra maintainers are responsible for keeping CI running properly 
and honestly reporting bugs.
If test fails because Jenkins is faulty or slow, you need to fix Jenkins. If 
test fails because there is a bug in the code, then you did a good job catching 
bugs. It is not your responsibility to fix the bug. You merely should report it 
to committers.

Thanks,
Junyuan Xie


On 2017-11-19 16:07, Gautam <gautamn...@gmail.com> wrote: 
> -1
> 
> Please see inline.
> 
> On Nov 19, 2017 12:51 PM, "Eric Xie" <j...@apache.org> wrote:
> 
> Hi all,
> I'm starting this thread to vote on turning off protected master. The
> reasons are:
> 
> 1. Since we turned on protected master pending PRs has grown from 40 to 80.
> It is severely slowing down development.
> 
> 
>      Turning protection off, will give you ability to merge the code which
> has build failure. How and more importantly who will be best judge to
> figure out what's is wrong ? If CI is a problem then we have people from
> infra team, who are sort of 'on call" day and night trying to fix.
> Including me trying to fix the slave at 2 am in night. I have seen
> commiters sending PRs and if it fails without even looking at the
> reason,which could be just a temporary error, they reach out to infra team
> immediately. So I don't agree that we should turn off the protected branch
> just for the sake of speed. We should care more on quality than speed.
> 
> 
> 2. Committers, not CI, are ultimately responsible for the code they merge.
> You should only override the CI when you are very confident that CI is the
> problem, not your code. If it turns out you are wrong, you should fix it
> ASAP. This is the bare minimum requirement for all committers: BE
> RESPONSIBLE.
> 
> How do we make sure that this in deed happens?
> 
> I'm aware of the argument for using protected master: It make sure that



> master is stable.
> 
> Well, master will be most stable if we stop adding any commits to it. But
> that's not what we want is it?
> 
> No we are not saying don't add anything in master, we are just saying
> please don't add bad code to the master. And yes I have seen bad code has
> been merged to the master when protected branch was not enabled.
> 
> Protected master hardly adds any stability. The faulty tests that breaks
> master at random got merged into master because they happened to succeed
> once.
> 
> That's not true, it filter out one of the important aspect that at least
> when code was merged it completed the whole cycle of build and test. Sure
> flaky test we can track down.
> 
> Thanks,
> Junyuan Xie
> 

Reply via email to