Need permissions for github.com/openshift/docker-distribution about image-registry HOT 10 CLOSED

@mfojtik told me that I don't need access (maybe only for rebase), but we have to setup a some job which will cherry-pick the commits against the vendor to the github.com/openshift/docker-distribution repository.

openshift/docker-distribution#1

from image-registry.

@bparees for the docker/distribution, you're likely to have your forks and origin is likely to have a different set. We'll want to be able to deconflict the branch names and you'll want to decide how you'd like to manage your branches.

I'd recommend making changes here, running CI here, merging here, and pushing back out, but you are unlikely to conflict with anyone (you're a different level after all and the set of modifying people is small), so it could be manageable the other way around.

As for permissions, I think that @bparees can merge into our fork and he's the likely approver anyway. I'd like to start by keeping it tight.

from image-registry.

@deads2k are you suggesting we'll have an "image-registry" and an "origin" branch of github.com/openshift/docker-distribution ?

from image-registry.

@deads2k are you suggesting we'll have an "image-registry" and an "origin" branch of github.com/openshift/docker-distribution ?

I'm saying it deserves some thought. Right now image-registry is using release-2.6.2. I pinned you to a SHA so you could sort out what makes the most sense, but that's what you were using when you moved repos. By contrast, openshift is using edc3ab2 (which I think is master) to match kubernetes.

But what would happen if kube wanted to use the same version and pin it and we needed patches for openshift/kube and you needed patches for image-registry? Would we expect to have the same set of patches? Would we accept having different patches? I suspect that in such a case, we'd accept having different patches, anticipating that yours are more invasive. The same way that a kube-apiserver built of openshift/kubernetes is likely to accept a different level of something like say k8s.io/apiserver than openshift/origin since the needs are different. kube-apiserver would remain close and origin would drift as much as is required.

from image-registry.

yeah, i get why we could end up there (perhaps already are there).

just wanted to confirm that "openshift fork with branch per dependent project" was the model we were intending to adopt. presumably:

1. image-registry won't be the last repo to carry a common dependency (at a different level) with origin.
2. docker-distribution won't be the last fork in this situation

so making sure we have a real plan for managing those is important.

from image-registry.

yeah, i get why we could end up there (perhaps already are there).

just wanted to confirm that "openshift fork with branch per dependent project" was the model we were intending to adopt. presumably:

image-registry won't be the last repo to carry a common dependency (at a different level) with origin.
docker-distribution won't be the last fork in this situation
so making sure we have a real plan for managing those is important.

I think its a plan that makes sense. We only got all the forks sync'ed out a few weeks ago, so the plan hasn't been particularly well considered yet. If it makes sense to you and it makes sense to me, we probably get to make that the plan going forward. release-2.6.2 for origin 3.7 and image-registry-release-2.6.2 for image-registry 3.8?

from image-registry.

i don't know that i'd want to include versions in the branch names. what does it buy us? just seems like another thing to have to maintain going forward.

also i don't think we should consider origin special/default at this point, so i'd expect it to be "origin-whatever" and "image-registry-whatever"

from image-registry.

i don't know that i'd want to include versions in the branch names. what does it buy us? just seems like another thing to have to maintain going forward.

The version in the branch names gives you a stable branch to depend on for your maintenance streams. 2.6.2 is the docker/distribution version, not the image-registry version. Because you have patches on top, you cannot rebase that branch on a new docker/distribution level without rewriting history and losing the branch to do maintenance on for past releases. That's why we have openshift/kubernetes:release-1.8.1.

also i don't think we should consider origin special/default at this point, so i'd expect it to be "origin-whatever"

That's pre-existing. Branches got made for 3.7 and we shouldn't rewrite those. As more pieces move out, it will be less contentious.

from image-registry.

ok.

from image-registry.

@legionus @deads2k i've created branch image-registry-release-2.6.2 based on the current vendor dependency of image-registry:
https://github.com/openshift/docker-distribution/tree/image-registry-release-2.6.2

I don't know who we want to have permissions to update that long term, but for now @legionus, just find a project commiter (any of the team leads) and we can merge it.

from image-registry.