Hacker News Reader

Comment by chias | Hacker News Reader

> "it's a feature request not a bug" shows Stephen did not even understand the problem he introduced.

He clarifies a little bit further down the thread:

> It's not a bug because it's working exactly as designed. We're very aware that you regard it as a misdesign.

If a project / community has adopted specific definitions for given words such as "bug", "feature request", etc., then IMO you should not get mad at people for using them as defined.

You may feel strongly that the auto-updating feature is a terrible idea in application, and you may even disagree with this project's decision to define a "bug" as "something that isn't working as designed", and that's fine. But I don't think it suggests that Stephen does not understand the issue, or did not read the thread.

View on HN

"bug" vs "feature" is a silly debate about semantics until someone uses it as a justification to push back releasing a fix. Bugs get fixed immediately, but feature requests can wait.

And also, who says that mis-designed features aren't bugs? In this case, they designed a bug, and shipped it.

Introducing an entirely new user-facing dialog option into the upgrade install flow doesn't sound like a 'bug fix' to me in any system. That's completely new UX, localization, security concerns, documentation...

Autoupgrading might totally be a misfeature for your usecase, but it's how this program works. If you don't want it to do that, then uninstall it.

> but it's how this program works

Or how it doesn't work, in this case.

> If you don't want it to do that, then uninstall it

And use what? There are no alternatives. Should I quit my job while I'm at it? Maybe I can just downgrade it .... oh wait ..

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.

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.

> 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.

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.

> 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?

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.

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.

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.

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?

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.

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.

> 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.

Good point, thank you for the correction.

> 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.

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.

> 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.

"Just don't use it. Just quit your job, stop paying your rent". This advice is precisely as useful as people that scream "move to Canada" at anyone who suggests we make any political progress.

It benefits everyone if we improve software. It benefits nobody if everyone never reports their problems and simply quietly disappears and quit their job when something in the software they use needs to be fixed -- and I think it's pretty obvious that course of action is unreasonable and unworkable.

I don't understand. We are talking about Docker Desktop for Mac, right? The piece of free-of-charge software that makes it a bit more convenient to use docker (which let's be clear is a Linux tool) from a Mac?

If you don't like the way that convenience is provided to you, then yes, you don't need to use it, and that is not tantamount to telling you to give up and go move to Canada.

The developers have chosen to implement autoupdating.

That meant that in December they pushed a version which had a bug in it, and users received the bugged version. Then they pushed a version with a fix, and users received the version with the fix.

That doesn't seem worth throwing a tantrum over.

Did you read the thread?

- Docker for Mac has no alternative.

- Docker for Mac periodically ships bugs that make the program (and Docker itself) unusable.

- Devs cannot downgrade -- so their workday can be productive and not wasted on fighting with the tool.

You seem to be implying that people are entitled. I suppose technically this can be true but Docker for Mac is viewed as a critical infrastructure and thus people should have venues to make it workable even if the latest version is bugged. They ask for choice and are against force automatic updating to the latest version.

> That doesn't seem worth throwing a tantrum over.

Such emotional reactions cast a doubt on whether you are arguing in good faith.

Exactly. The fact they pushed back for this to be fixed under a new feature release vs bug hotfix, is simply salt on the wound.

I think that's a silly definition of a bug. If it breaks the product, it's a bug. It doesn't matter if it was created at dev time or design time.

Hell, a huge chunk of dev work is rethinking design decisions that are misguided/under specified/break things because you only see these issues once you start having to implement details.

similar to "feature not a bug" happened here https://news.ycombinator.com/item?id=26468421 the dev said its not a bug visual impaired users cant see things in his app and went full agressive on people reporting. so hard he blocked any new people from reporting issues too and hid comments/discussion about imrpoving the situation

someone else said "this is how you get forked" and they are right for foss things, but docker isnt so trickier

Sure, I don't think they will be able to be forked in the traditional sense, but docker is not the only container runtime.

It would be reasonable for people to build better tooling around rkt, or jump on the podman bandwagon

Reply on news.ycombinator.com