I barely remember CI caught bugs except for lint, but it definitely slows down the code merge.
I understand the general concerns for removing master protection. So I propose to use the dev branch to merge changes until the CI is stable. And make the nightly build build the dev branch instead of master. Best Mu > On Nov 30, 2017, at 11:34 AM, Gautam <gautamn...@gmail.com> wrote: > > I believe few of the committers voted -1 and those who favored they have > put pre-condition. > As mentioned before and mentioning again without protected master it will > be hard to debug the build failure. > And I am sure everyone here is aware of the challenges which CI faces every > day, not having protected master makes it more difficult. > > -Gautam > > > > > > > > >> On Thu, Nov 30, 2017 at 11:24 AM, Eric Xie <j...@apache.org> wrote: >> >> Since committers voted for +1. We consider this vote passed. >> >> Thanks, >> Eric >> >> >> >>> On 2017-11-19 12:51, "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. >>> >>> 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. >>> >>> 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? >>> >>> Protected master hardly adds any stability. The faulty tests that breaks >> master at random got merged into master because they happened to succeed >> once. >>> >>> Thanks, >>> Junyuan Xie >>> >> > > > > -- > Best Regards, > Gautam Kumar
