I’m reminded of Joe Armstrong and OOP:
You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
Filing a whole container seems like crazy overkill for 95% of bugs.
I can just imagine some private keys that were part of a container build making it to a bug report.
Overkill for the common case, but it’d be insanely useful for difficult to reproduce bugs.
Like a core dump, but for shitty languages / environments.
Fortunately openbsd doesn’t support containers, so now I can look forward to zero bug reports in the future.
But really, I usually pass on bug reports that come with their instruction manuals. Like “download this program and 20 libraries and find the bug…” putting those 20 libraries in a container doesn’t inspire me to find the bug. Send me 10 lines of code that demonstrates the bug or I (very safely) assume the bug is somewhere in your setup and not in my code.
This is probably the best counter on your implied complexity and QA arguments. The container ecosystem is fast-moving, fad-driven, and complex. That brings these pieces of software plenty of bugs. Then, the QA ain’t so good. This combination means there’s a decent chance of a bug in the submitter’s, local configuration. Now, one must decide if it’s worth the effort to look at code showing the bug or recreate that configuration that supposedly shows the bug.
Better to just look at the code showing the bug and fix it if it’s there. Ask for configuration leading to it only if necessary.
So basically the idea is don’t do any investigation yourself trying to get a minimally reproducible test case. Just send a giant container with the code and let some one else debug it.
Count me out.
All the developers will magically have time to dig around in someone else’s container, or ask for instructions on where the bug is.
This is just awful and I hope it goes away. The Dockermania is almost too much already.
I had an epic knee-jerk moment reading the title of this. How did the saying go? “When all you got is a hammer, everything starts to look like a nail”? I understand the need to have better insight into bugs, and all that, but I’m not sure that shipping the entire environment is the way to go. Because let’s face it; you’re going to file a gazillion containers for all the sweet sweet dockerized fleet of microservices, aren’t you?
If someone sends me a container as a bug report I’m going to fix his bug and ship the fix back as a compiled binary in the container. This just shifts the work having the submitter to do at least minimal effort in diagnosing the problem to dumping it all on the code maintainer.
Hm, I’m split on this.
I did support work for the Padrino framework for a while. Padrino - for those of you that don’t know - takes the “some assembly required” approach. We ship a set of libraries that form a framework, but want each of those libraries to work in seperation and not hide away the mechanics of assembly (this vastly improves - in my opinion - future extension for project needs).
We had roughly two sorts of bugs: proper library bugs, where function A returns the wrong output for input B. For these - file a properly researched bug!
The second class of bugs were assembly errors, probably due to an unexpected environment or a user doing unexpected things. Often, those users had to be given the benefit of being beginners. In those cases, the back and forth of “can I have the Ruby version? Are you using intermediates? etc..” would have been much easier solved for me by the other person just sending me a VM or a docker container. I would prefer a VM though, as Docker is just hell to inspect.
There’s a real issue with that approach is though: this approach only works when the app is open and can be supplied to you. Most of these apps are internal, though, so you are back to trying to find a minimal case first.