@dnephin @mlaventure I'm afraid if we use
/x/ for everything we might never move away from it.
That's why in my proposal, only
engine is behind
/x/ since will will be heavily modified (componentized)
I feel like
pkg are somehow stable and I don't see the need to put them behind
Same for the moby tool, I was thinking about using
/cmd/ for go gettable binaries, so I don't see why to put it behind
@mlaventure @dnephin regarding the versioning, maybe it's an unpopular opinion, but I don't think it should be part of the url. many of our pkgs are so small, I don't want to have to manage versions on each and everyone of them, including when to bump the version.
I don't see the custom URLs replace vendoring, so ppl will still vendor our pkgs and pin the commit then need.
@dnephin by external pkgs, I think we only need "Item 2 - Split packages with poor cohesion" from the reorganization of pkg. once this is done, we route the custom urls to the pkg in moby/moby and then gradually when we move the pkg to another repo, update the custom URLs, it won't impact users.
@chanezon every time we brought up
mo.by concerns were raised about
.by and since it's not something users would time often, I think something longer is fine.
@bmitch3020 I was thinking of
/cmd for the actual binaries, no matter where they are hosted
go get go.mobyproject.org/cmd/moby would get me
go get go.mobyproject.org/cmd/linuxkit would get me
For the rest we could use