3 ms·

Hi, having started Docker I am of course biased, but I thought I'd bring some data to this conversation. Last 30 days on Docker Compose: 45 PRs merged from 26

by shykes 11y ago

Hi, having started Docker I am of course biased, but I thought I'd bring some data to this conversation. Last 30 days on Docker Compose: 45 PRs merged from 26 people Full time Docker employees on Compose: 1 Last 30 days on Docker Machine: 39 PRs merged from 33 people Full time Docker employees on Machine: 1 Last 30 days on Docker Swarm: 50 PRs merged from 21 people Full time employees on Swarm: 3 Last 30 days on Docker core: 265 PRs merged from 161 people Full time employees on core: 8 The lmctfy authors are now core maintainers of runC (and its underlying libcontainer) which they built together with Docker core maintainers. Together they built something robust and operationally sound, based on their combined experience running containers in production. Overall, lots of great tools being developed, at different levels of maturity, some focused on low-level operations and some focused on helping developers. I don't understand the negativity. Edit: the lmctfy authors, unlike the grand-parent in this thread, have been super pragmatic about the pros and cons of the Google stack vs others. They realize that it's a big and complex world out there, and that not every computer system can make the same simplifying assumptions as Google. Only a relatively unexperienced SRE would assume that you can build any system on top of their employer's custom tools, unmodified. To take an obvious example: nested cgrouls and performance profiles are really sweet, but last I checked, net namespace support was not a priority because "we don't need it at Google". Welcome to the real world, GauntletWizard.

icebraining 11y ago
As a side note, is there any way to view a graph of open PRs over time? It could be a good test of the health of a repo.
- shykes 11y ago
  I just look at the "pulse" section on github. We also have an internal tool which we query for more complex queries (contributor retention across projects, things like that).
GauntletWizard 11y ago
I'm sorry if I sounded condescending to you, but it's pretty clear that organizations with a strong engineering focus need a strong and clear vision of how components integrate - and the current state of docker actively discourages that. The ability to shove tools together willy-nilly, hacking around their incompatibilities, does not a solid platform create. Some of your biggest features, like the various networking modes, are complete misfeatures; The only reason you need bridge mode is bad network layout, the only reason for container is because you've screwed it up and you're using bridge mode. Both the dockerfile reference and run reference are incredibly long and filled with references to strange interactions with other features. The fact that features don't interact in ways that can be simply reasoned about but instead clarification is required is a huge red flag in core infrastructure. Docker has done wonderful things in terms of getting people to think about their services rather than their hosts. But each new feature reduces that advantage, as it allows people to take lazier approaches to integrate their systems, and those approaches flat-out don't work.

by shykes 11y ago

icebraining 11y ago

As a side note, is there any way to view a graph of open PRs over time? It could be a good test of the health of a repo.

shykes 11y ago
I just look at the "pulse" section on github. We also have an internal tool which we query for more complex queries (contributor retention across projects, things like that).

GauntletWizard 11y ago

I'm sorry if I sounded condescending to you, but it's pretty clear that organizations with a strong engineering focus need a strong and clear vision of how components integrate - and the current state of docker actively discourages that. The ability to shove tools together willy-nilly, hacking around their incompatibilities, does not a solid platform create. Some of your biggest features, like the various networking modes, are complete misfeatures; The only reason you need bridge mode is bad network layout, the only reason for container is because you've screwed it up and you're using bridge mode. Both the dockerfile reference and run reference are incredibly long and filled with references to strange interactions with other features. The fact that features don't interact in ways that can be simply reasoned about but instead clarification is required is a huge red flag in core infrastructure. Docker has done wonderful things in terms of getting people to think about their services rather than their hosts. But each new feature reduces that advantage, as it allows people to take lazier approaches to integrate their systems, and those approaches flat-out don't work.