4 ms·

Implementing new UI required to fix a bug due to functionality oversight, is still a bug. This broke production environments. That is a bug. Bugs can introduc

Implementing new UI required to fix a bug due to functionality oversight, is still a bug. This broke production environments. That is a bug. Bugs can introduce new development to meet acceptance criteria, if that is the right way to solve the bug. Edit: kelnos accurately pointed out that I should have said development environment, and not production.

jameshart 6y ago
No, a bug in the new release that the autodeployer autodeployed was the bug. The autodeployer worked flawlessly. Presumably it also would flawlessly autodeploy the fix for that bug when it gets released.
- asidiali 6y ago
  > No, a bug in the release...was the bug. So, there was a bug. A UX bug. Bugs aren’t software-exclusive. I may be misunderstanding your point.
  - pvorb 6y ago
    But still, if there was no bug in 3.0.2, people wouldn't have tried to downgrade to 3.0.1 again. So the bug was not in 3.0.0, nor in 3.0.1, but only in 3.0.2.
    - lopatin 6y ago
      > people wouldn't have tried to downgrade to 3.0.1 again What's the point of having versions if you can't install them?
      - pvorb 6y ago
        There's a point for the developers and to communicate features and bugfixes. And they still help in supporting installations. But you are correct, they become less important. They (patch versions at least) don't necessarily have to be communicated to users.
    - asidiali 6y ago
      So a user experiences a separate bug in 3.0.2, tries to downgrade to 3.0.1, and is unable to as they are re-upgraded right back to 3.0.2. Do you not consider that a new additional bug, that one is unable to downgrade to 3.0.1, a stable build, at that point? I’d argue that’s a new bug that wasn’t previously discovered.
      - pvorb 6y ago
        To me the question is, if it's still a bug once the original bug in 3.0.2 got fixed. I'd argue no, you might argue yes. I think auto-upgrades of Docker are totally fine if it makes the lives of Docker devs easier and they can concentrate on more meaningful things. After all, the majority of the user base is not paying a single cent for the software. If a paying customer complains about auto-upgrades and wants to buy into their own support branch, that's a different story.
        asidiali 6y ago
        Thanks for elaborating, yes, I think we probably just disagree on that part. What if someone upgrades and they just don’t like the new functionality of 3.0.2 and they want to go back to 3.0.1 just because? This idea that bug-free releases would prevent downgrades is simply unrealistic IMO - as another comment pointed out, why even have versions then?
        pvorb 6y ago
        I understand your position, but the example here feels a bit off. If we were talking about an auto-upgrade from 2.x.y to 3.0.0 I'd probably agree with you. For a minor version upgrade maybe, too. But why would I want less bugfixes for the exact same feature set? Yes, there was a bug in a fix. But as soon as that's fixed, everyone should be fine. I've no idea if Docker's auto-upgrades also include minor an major versions, though.
        asidiali 6y ago
        That’s a good point, I think that makes sense. Maybe not a good idea for larger releases like you said, but yeah for bug patches, why wouldn’t I want those. That’s fair.
kelnos 6y ago
> This broke production environments. This broke development environments. I really hope no one is using Docker Desktop running on Mac in production. Not to trivialize the issue; lost productivity due to a a bug in a software update sucks. But people are not getting irate customer phone calls or losing revenue because of product downtime due to this.
- asidiali 6y ago
  Good point, thank you for the correction.
- k_sze 6y ago
  > But people are not getting irate customer phone calls or losing revenue because of product downtime due to this. It could be an indirect cause of irate calls because there’s a bug in production but the dev environment is broken by Docker’s auto-update so the devs can’t work on a fix for the production bug.
  - jackinloadup 6y ago
    Dude! This exactly. Think about having to explain that to NASA. Ahh sorry I can't fix this major SEC issue because our developers can't do a release atm. It went over as well as you'd think. I had to pull out our actual contract to be like "Well... we actually have like 8 days to fix this criticality of SEC so..." Then prayed to Al Gore and Linus Torvalds that what ever this dependency was would be resolved before I got my ass handed to me.
- dragonwriter 6y ago
  > This broke development environments. I really hope no one is using Docker Desktop running on Mac in production. If it breaks even just my desktop working environment, and that impairs my ability to remediate a production problem, it's causing production downtime. Dev environments aren't decorative.

jameshart 6y ago

No, a bug in the new release that the autodeployer autodeployed was the bug. The autodeployer worked flawlessly. Presumably it also would flawlessly autodeploy the fix for that bug when it gets released.

asidiali 6y ago
> No, a bug in the release...was the bug. So, there was a bug. A UX bug. Bugs aren’t software-exclusive. I may be misunderstanding your point.
- pvorb 6y ago
  But still, if there was no bug in 3.0.2, people wouldn't have tried to downgrade to 3.0.1 again. So the bug was not in 3.0.0, nor in 3.0.1, but only in 3.0.2.
  - lopatin 6y ago
    > people wouldn't have tried to downgrade to 3.0.1 again What's the point of having versions if you can't install them?
    - pvorb 6y ago
      There's a point for the developers and to communicate features and bugfixes. And they still help in supporting installations. But you are correct, they become less important. They (patch versions at least) don't necessarily have to be communicated to users.
  - asidiali 6y ago
    So a user experiences a separate bug in 3.0.2, tries to downgrade to 3.0.1, and is unable to as they are re-upgraded right back to 3.0.2. Do you not consider that a new additional bug, that one is unable to downgrade to 3.0.1, a stable build, at that point? I’d argue that’s a new bug that wasn’t previously discovered.
    - pvorb 6y ago
      To me the question is, if it's still a bug once the original bug in 3.0.2 got fixed. I'd argue no, you might argue yes. I think auto-upgrades of Docker are totally fine if it makes the lives of Docker devs easier and they can concentrate on more meaningful things. After all, the majority of the user base is not paying a single cent for the software. If a paying customer complains about auto-upgrades and wants to buy into their own support branch, that's a different story.
      - asidiali 6y ago
        Thanks for elaborating, yes, I think we probably just disagree on that part. What if someone upgrades and they just don’t like the new functionality of 3.0.2 and they want to go back to 3.0.1 just because? This idea that bug-free releases would prevent downgrades is simply unrealistic IMO - as another comment pointed out, why even have versions then?
        pvorb 6y ago
        I understand your position, but the example here feels a bit off. If we were talking about an auto-upgrade from 2.x.y to 3.0.0 I'd probably agree with you. For a minor version upgrade maybe, too. But why would I want less bugfixes for the exact same feature set? Yes, there was a bug in a fix. But as soon as that's fixed, everyone should be fine. I've no idea if Docker's auto-upgrades also include minor an major versions, though.
        asidiali 6y ago
        That’s a good point, I think that makes sense. Maybe not a good idea for larger releases like you said, but yeah for bug patches, why wouldn’t I want those. That’s fair.

kelnos 6y ago

> This broke production environments. This broke development environments. I really hope no one is using Docker Desktop running on Mac in production. Not to trivialize the issue; lost productivity due to a a bug in a software update sucks. But people are not getting irate customer phone calls or losing revenue because of product downtime due to this.

asidiali 6y ago
Good point, thank you for the correction.
k_sze 6y ago
> But people are not getting irate customer phone calls or losing revenue because of product downtime due to this. It could be an indirect cause of irate calls because there’s a bug in production but the dev environment is broken by Docker’s auto-update so the devs can’t work on a fix for the production bug.
- jackinloadup 6y ago
  Dude! This exactly. Think about having to explain that to NASA. Ahh sorry I can't fix this major SEC issue because our developers can't do a release atm. It went over as well as you'd think. I had to pull out our actual contract to be like "Well... we actually have like 8 days to fix this criticality of SEC so..." Then prayed to Al Gore and Linus Torvalds that what ever this dependency was would be resolved before I got my ass handed to me.
dragonwriter 6y ago
> This broke development environments. I really hope no one is using Docker Desktop running on Mac in production. If it breaks even just my desktop working environment, and that impairs my ability to remediate a production problem, it's causing production downtime. Dev environments aren't decorative.