[anuila]

I think the difference is that they expect to not break tests most of the time. So most of the time this just saves time.

It’s like when you merge a documentation PR while the tests are still running: You’re pretty sure that the tests won’t break. With this solution however you’ll still be pinged if they do break, later.

[stkdump]

If one developer doesn't break it 98% of the time, then for 200 devs you have a chance of .98^200=2% of not breaking it. And for one person trying to quickly get the fix ready while he might have an urgent family situation you have 199 devs who can't get their stuff in, of which at least 20 are under pressure to deploy their fixes quickly themself. It sounds like creating a hard problem for individuals for solving a mediocre problem for the team.

[hinkley]

From personal experience, statistical clustering seems to set the narrative.

You don’t even need to hit a 2% success rate to get people agitated. Consecutive failed builds that happen every few weeks will eventually happen when someone really needs to get something out Right Now and that incident will come to define their experience, especially if it happens two or three times. Even if it’s just to people they know instead of themselves.

Anything that happens once a day happens “all the time.” For some people, that’s true for once a week. For others, if it happened twice in two weeks and once every six weeks thereafter.

[rendall]

The dev does have the option of reverting their change.

If significant numbers of devs found the whole process stressful, I wonder if it would help to make the reversion happen automagically after, say, 24 hours, if the dev hasn't committed anything in that time

Devs who have called in sick or over the weekend or attending a wedding or long-planned vacation don't have to think about it.

[stkdump]

> The dev does have the option of reverting their change.

Stopping the world seems like an automated process. So should reverting be. In fact, there should be no stopping the world at all, just reverting if the dev can't fix it within 72 hours. There might be cases where automatic reverting doesn't work, but those should still be managed through organizational processes, not by stopping the world.

[rendall]

I agree.

I'm an unusual American, in that I consider healthy work-life balance to be top priority, at least for everyday employees (founders and such have a different path).

I do try to make room for the idea that my understanding of this is likely superficial, and that there may be things that I am missing, here.

[conradludgate]

I dont see why this would block other devs merging in their work. And what kind of teams do you work in where you can't politely ask for someone's help when you have to deal with a personal issue?

[stkdump]

> I dont see why this would block other devs merging in their work.

Read the article. It says:

> If the CI job remains broken for more than 72 hours, all deployments to GitHub.com are halted

Edit: it even creates the perverse incentive of trying to get your own stuff in quickly before the 72h window closes that s/o else caused.

[malkia]

I mean the change can be reverted, if it's not fixed, automatically or not.