profile
viewpoint

pull request commentcuelang/cue

Fix typos in 'cue mod'

Hi, I signed the Google CLA, but the cla:no tag is still in effect. After reading the FAQ, I believe it is because the email on my Google account is not the email I used in my commit.

Is the only solution really to add the email I use on my commit to my Google account? This seems pretty intrusive. I do not want Google to manage that address. Did I misunderstand the instructions in the doc? Can I configure my CLA to use the same email as my commit without adding that email to my Google account?

shykes

comment created time in 2 months

PR opened cuelang/cue

Fix typos in 'cue mod'
+2 -2

0 comment

1 changed file

pr created time in 2 months

push eventshykes/cue

Solomon Hykes

commit sha 109888e6d6b14df74cd764b3e08c465c1c3300b1

Fix typos in 'cue mod'

view details

push time in 2 months

issue commentmoby/moby

Rename moby to docker

You make a good point @asim that there is no obvious place for Docker users to start participating in the open-source community. Visiting the website just now, there is https://www.docker.com/community/open-source , which does a good job at introducing the various projects. I think that's a good start which could be further improved. The community slack is also a great place.

Personally I feel that the best place to make your first steps as a contributors could be the Docker tools themselves. Maybe the docker CLI could have a plugin that helps you report bugs, propose features, and even make contributions? It could make for a more personnalized and interactive experience, and it would also leave the maintainers free to decide of their repository structure, and change their minds over time.

It just makes sense to me that getting support for a product, and suggesting changes, should be considered part of the product experience itself.

asim

comment created time in 2 months

issue commentmoby/moby

Rename moby to docker

@AkihiroSuda actually I think docker run should be considered a devtool feature, not infrastructure.

On the one hand, the consensus in the infrastructure community seems to be: avoid wrapping docker run for runtime infrastructure; consider using containerd instead, or another competing infrastructure project such as systemd, lxd, cri-o, etc.

On the other hand, if you're a developer, or if you're responsible for developer productivity, you rely on docker run and you're generally happy with it. I would argue that, if docker run were free from the burden of being both infrastructure and a devtool at the same time, it could be an even better devtool. For example, maybe it could support more backends? What if I could point docker run at any Kubernetes, Swarm, or ECS cluster, and get a running container using the same familiar and consistent interface? This is just an example, I don't know how much that particular feature is needed.

The point is: the infrastructure community does not want to use docker run. The developer community does. Therefore, I recommend focusing on those users who actually enjoy the tool and want to use it more.

asim

comment created time in 2 months

issue commentmoby/moby

Rename moby to docker

The goal of the Moby/Docker split was pretty simple: separate the infrastructure code from the dev tools, so we can separate the "Docker is infrastructure" people from the "Docker is a dev tool" people.

This separation of people into separate communities was crucial. because infrastructure people and devtool people have different goals and priorities, and it was not sustainable for one project to try and make both groups happy. It created too much conflict, too many misunderstandings, and ultimately it burned people out (myself included).

The Moby/Docker split aimed to resolve this conflict by saying "Docker is a dev tool; Moby is infrastructure. If you're interested in dev tools, look at Docker. If you're interested in infrastructure, look at Moby". Unsurprisingly, this created confusion and sometimes anger for infrastructure people, because it forced them to change their definition of Docker. On the other hand, people who already thought of Docker as a dev tool were not confused, because they were not required to change their definition.

Ultimately the separation of communities did take place, and it did help increase productivity and decrease drama. But in retrospect, the biggest factor was not the Moby split, but the containerd split. With CRI allowing for Kubernetes users to choose their favorite runtime instead of being stuck with dockerd, a lot of the angry Kubernetes people went away, either to the containerd repo, or to cri-o, or whatever else people run pods on these days.

I don't know whether reverting the Moby split is a good idea (my instinct tells me it's not worth the trouble, but I don't know). However, please, please maintain a clear separation between infrastructure and devtools. And do not make Docker an infrastructure project! It is not, and never should have been. Unless you've been a full-time maintainer on Docker pre-split, you have no idea how painful it is to mix devtools development and infrastructure development in the same open-source project, at large scale. I would not wish it on my worst enemy.

Whatever you decide, I wish you best of luck. And while I'm at it: thank you for caring enough to bring up this important topic :)

asim

comment created time in 2 months

delete branch shykes/buildx

delete branch : patch-1

delete time in 2 months

PR opened docker/buildx

Clarify documentation structure

Move a paragraph in README to clarify where it fits in the structure.

  • Before the move, the paragraph seems to apply to the --output=local section when in fact it applies to the entire --output section. This is especially confusing for the sentence "if just the path is specified as a value, buildx will use the local exporter with this path as the destination".

  • After the move, it is clear that the paragraph applies to --output

+16 -17

0 comment

1 changed file

pr created time in 2 months

push eventshykes/buildx

Solomon Hykes

commit sha d7adb9ef6e8d89e4f2e4214609acd1859141eb38

Clarify documentation structure Move a paragraph in README to clarify where it fits in the structure. - Before the move, the paragraph seems to apply to the `--output=local` section when in fact it applies to the entire `--output` section. This is especially confusing for the sentence "if just the path is specified as a value, `buildx` will use the local exporter with this path as the destination". - After the move, it is clear that the paragraph applies to `--output`

view details

push time in 2 months

fork shykes/buildx

Docker CLI plugin for extended build capabilities with BuildKit

fork in 2 months

issue commentdocker/buildx

--progress=raw

I agree --progress=json is better. Thanks.

shykes

comment created time in 3 months

issue openeddocker/buildx

--progress=raw

It would be awesome if buildx <bake|build> supported --progress=raw, which would output a json stream with all the structured status information, to pipe into custom progress display helpers without having to patch buildx itself.

My understanding based on Tibor's explanation is that the internal plumbing is already in place for accessing the structured status info, it's just that right now it requires linking against buildkit itself.

created time in 3 months

created repositoryshykes/Foo-Bar-

created time in 3 months

startedstreamlit/streamlit

started time in 4 months

fork shykes/cue

Validate and define text-based and dynamic configuration

https://cuelang.org

fork in 4 months

startedcuelang/cue

started time in 4 months

more