5 ms·

This doesn't seem like all that great of a solution to me. The strict requirement to have a passing build is replaced with the fear that you'll be the one that

This doesn't seem like all that great of a solution to me. The strict requirement to have a passing build is replaced with the fear that you'll be the one that broke the build. So you'll end up running these tests before you merge anyways, right? What has changed?

anuila 6y ago
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.
- malkia 6y ago
  I mean the change can be reverted, if it's not fixed, automatically or not.
- stkdump 6y ago
  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.
  - conradludgate 6y ago
    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 6y ago
      > 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.
  - hinkley 6y ago
    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 6y ago
    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 6y ago
      > 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 6y ago
        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.
fuzzybear3965 6y ago
What has changed is that deployments happen 3x faster. I would guess that this wouldn't introduce more or less build breaks. People will do as they've been doing. The psychological argument can be made that people could be either less safe with their commits, since they have 72 hours to fix any problem breaking a long-running CI job, or they could be more safe with their commits, fearing they'll break a long-running CI job. Personally, I don't think that either position has a lot of strength.

anuila 6y ago

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.

malkia 6y ago
I mean the change can be reverted, if it's not fixed, automatically or not.
stkdump 6y ago
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.
- conradludgate 6y ago
  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 6y ago
    > 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.
- hinkley 6y ago
  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 6y ago
  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 6y ago
    > 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 6y ago
      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.

fuzzybear3965 6y ago

What has changed is that deployments happen 3x faster. I would guess that this wouldn't introduce more or less build breaks. People will do as they've been doing. The psychological argument can be made that people could be either less safe with their commits, since they have 72 hours to fix any problem breaking a long-running CI job, or they could be more safe with their commits, fearing they'll break a long-running CI job. Personally, I don't think that either position has a lot of strength.