So are you suggesting docker should merge and maintain support for a container spec they weren't involved with which, was created because docker is "fundamentally flawed"?
I'm sure the pull-request author knew that this would do nothing more than cause fuss in the community. Shykes comment seems to me like it was a response to what seems like a hardly legitimate PR and much like a PR stunt.
Docker has 722 contributors on github, I'm sure the community will discuss and decide what to do with this while I watch this battle play out and work with both products.
1. Rocket implementing the docker image format
2. Rocket PR'ing the rocket image format to docker.
It is 100% reasonable and likely a good business move to reject the PR, but the only reason to be mad about (1) is if it benefits the end user in a way that weakens Docker's market share, which it does.
Don't get me wrong, I think it's great the coreos guys are trying to make a bridge between the two projects, but so far, I don't see a need for this.
If I were a Docker user, and found some awesome app that only came packaged in App Container format, it'd be very valuable to have this compatibility.
(Docker's beefs here feel more like a company defending their turf than an open-source project, and that troubles me.)
As a user, it would be fantastic to run my App Container images on Docker hosts, and Docker images on Rocket hosts.
If only I could move my virtual machine images this easily and avoid high switching costs between platforms.
Shykes > just do it in your own project and let the best project win ... you have to choose one or the other
Bullshit. If it's open, let the best idea win. If this is a bad idea, then let the community examine it and it will lose on the merits.
Don't force me into a false dichotomy.