New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup merge automation for all kubernetes repos #6227

Open
spiffxp opened this Issue Jan 10, 2018 · 16 comments

Comments

Projects
None yet
9 participants
@spiffxp
Member

spiffxp commented Jan 10, 2018

/assign
/area prow
/sig contributor-experience
I've been doing this organically, here's an umbrella issue to keep track

The general process I've been following lately is:

  • File an issue with these steps
  • Create/update an OWNERS_ALIAS file that names the existing teams that have write/admin access to the repo
  • Create/update an OWNERS file with approvers based on the write/admin access teams
  • Configure prow to turn on the "approval" plugin for this repo
  • Configure prow/tide to include this repo in the tide query
  • Hold off if there are any objections or special cases

Issues used to add repos in the past:


EDIT: as of 2018-09-17

org/repo in sigs.yaml? has owners? has approve? in tide? branch protected?
kubernetes/kubelet missing
kubernetes/kube-scheduler missing
kubernetes/kube-proxy missing
kubernetes/kube-controller-manager missing
kubernetes-sigs/kind missing
kubernetes-incubator/spartakus no approve not in tide
kubernetes-incubator/rktlet no approve not in tide
kubernetes-incubator/reference-docs no approve not in tide
kubernetes-incubator/node-feature-discovery no approve not in tide
kubernetes-incubator/nfs-provisioner no approve not in tide
kubernetes-incubator/metrics-server no approve not in tide
kubernetes-incubator/kube-aws no approve not in tide
kubernetes-incubator/kube-arbitrator no approve not in tide
kubernetes-incubator/external-storage no approve not in tide
kubernetes-incubator/external-dns no approve not in tide
kubernetes-incubator/descheduler no approve not in tide
kubernetes-incubator/custom-metrics-apiserver no approve not in tide
kubernetes-incubator/cluster-proportional-vertical-autoscaler no approve not in tide
kubernetes-incubator/cluster-proportional-autoscaler no approve not in tide
kubernetes-incubator/cluster-capacity no approve not in tide
kubernetes-incubator/bootkube no approve not in tide
kubernetes-incubator/apiserver-builder no approve not in tide
kubernetes/website
kubernetes/utils
kubernetes/test-infra
kubernetes/steering
kubernetes/sig-release
kubernetes/sample-controller
kubernetes/sample-cli-plugin
kubernetes/sample-apiserver
kubernetes/repo-infra
kubernetes/release
kubernetes/publishing-bot
kubernetes/perf-tests
kubernetes/org
kubernetes/node-problem-detector
kubernetes/minikube
kubernetes/metrics
kubernetes/kubernetes
kubernetes/kubernetes-template-project
kubernetes/kubernetes-docs-zh
kubernetes/kubernetes-docs-ko
kubernetes/kubernetes-docs-ja
kubernetes/kubernetes-anywhere
kubernetes/kubectl
kubernetes/kubeadm
kubernetes/kube-state-metrics
kubernetes/kube-openapi
kubernetes/kube-deploy
kubernetes/kube-aggregator
kubernetes/kops
kubernetes/kompose
kubernetes/k8s.io
kubernetes/ingress-nginx
kubernetes/ingress-gce
kubernetes/heapster
kubernetes/git-sync
kubernetes/gengo
kubernetes/frakti
kubernetes/federation
kubernetes/features
kubernetes/examples
kubernetes/dns
kubernetes/dashboard
kubernetes/csi-api
kubernetes/contrib
kubernetes/community
kubernetes/code-generator
kubernetes/cluster-registry
kubernetes/cloud-provider-vsphere
kubernetes/cloud-provider-openstack
kubernetes/cloud-provider-gcp
kubernetes/cloud-provider-azure
kubernetes/cloud-provider-aws
kubernetes/client-go
kubernetes/cli-runtime
kubernetes/autoscaler
kubernetes/apiserver
kubernetes/apimachinery
kubernetes/apiextensions-apiserver
kubernetes/api
kubernetes-sigs/testing_frameworks
kubernetes-sigs/structured-merge-diff
kubernetes-sigs/poseidon
kubernetes-sigs/kustomize
kubernetes-sigs/kubebuilder
kubernetes-sigs/kubeadm-dind-cluster
kubernetes-sigs/kube-storage-version-migrator
kubernetes-sigs/gcp-filestore-csi-driver
kubernetes-sigs/gcp-compute-persistent-disk-csi-driver
kubernetes-sigs/federation-v2
kubernetes-sigs/cri-tools
kubernetes-sigs/cri-o
kubernetes-sigs/controller-tools
kubernetes-sigs/controller-runtime
kubernetes-sigs/contributor-site
kubernetes-sigs/contributor-playground
kubernetes-sigs/cluster-api
kubernetes-sigs/cluster-api-provider-vsphere
kubernetes-sigs/cluster-api-provider-openstack
kubernetes-sigs/cluster-api-provider-gcp
kubernetes-sigs/cluster-api-provider-aws
kubernetes-sigs/aws-iam-authenticator
kubernetes-sigs/aws-encryption-provider
kubernetes-sigs/aws-alb-ingress-controller
kubernetes-sigs/architecture-tracking
kubernetes-sigs/application
kubernetes-incubator/service-catalog
kubernetes-incubator/kubespray
kubernetes-incubator/ip-masq-agent
kubernetes-csi/livenessprobe
kubernetes-csi/kubernetes-csi.github.io
kubernetes-csi/external-snapshotter
kubernetes-csi/external-provisioner
kubernetes-csi/external-attacher
kubernetes-csi/drivers
kubernetes-csi/driver-registrar
kubernetes-csi/docs
kubernetes-csi/csi-test
kubernetes-client/ruby
kubernetes-client/python
kubernetes-client/python-base
kubernetes-client/javascript
kubernetes-client/java
kubernetes-client/haskell
kubernetes-client/go
kubernetes-client/go-base
kubernetes-client/gen
kubernetes-client/csharp

[1] - staging repos live in kubernetes/kubernetes/staging and so use whatever merge automation kuberentes/kubernetes has

@mattfarina

This comment has been minimized.

Show comment
Hide comment
@mattfarina

mattfarina Jan 11, 2018

Member

Why should all the repos have or use merge automation? What's the benefit for those that aren't using it today?

Member

mattfarina commented Jan 11, 2018

Why should all the repos have or use merge automation? What's the benefit for those that aren't using it today?

@stevekuznetsov

This comment has been minimized.

Show comment
Hide comment
@stevekuznetsov

stevekuznetsov Jan 11, 2018

Contributor

Why should all the repos have or use merge automation?

@mattfarina this was a conclusion that the steering committee reached when trying to define what constituted Kubernetes repos. Not sure if that doc got sent to the dev list, but here is a link: https://docs.google.com/document/d/1yauW9zMtWgXN8xh4q6144B2xBTPuIOLGc0L6aQPMj1I/edit?usp=sharing

Contributor

stevekuznetsov commented Jan 11, 2018

Why should all the repos have or use merge automation?

@mattfarina this was a conclusion that the steering committee reached when trying to define what constituted Kubernetes repos. Not sure if that doc got sent to the dev list, but here is a link: https://docs.google.com/document/d/1yauW9zMtWgXN8xh4q6144B2xBTPuIOLGc0L6aQPMj1I/edit?usp=sharing

@fejta

This comment has been minimized.

Show comment
Hide comment
@fejta

fejta Jan 11, 2018

Contributor

Benefit is a consistent experience between repos, which makes it easier to move around between them efficiently.

Contributor

fejta commented Jan 11, 2018

Benefit is a consistent experience between repos, which makes it easier to move around between them efficiently.

@jberkus

This comment has been minimized.

Show comment
Hide comment
@jberkus

jberkus Jan 11, 2018

The other benefit is that it means that all repos can be included in the general release process where required. Realistically, the release team cannot manage or even monitor repos which use a completely different workflow and labels from everything else. Now, some sub-projects will never have this concern, but a lot will.

jberkus commented Jan 11, 2018

The other benefit is that it means that all repos can be included in the general release process where required. Realistically, the release team cannot manage or even monitor repos which use a completely different workflow and labels from everything else. Now, some sub-projects will never have this concern, but a lot will.

@mattfarina

This comment has been minimized.

Show comment
Hide comment
@mattfarina

mattfarina Jan 11, 2018

Member

@jberkus why would everything use the general release process? For example, there is talk of moving kubectl out of k8s and having an independent release process and timing from k8s. It would decouple them. What benefit would kubectl have to use the general release process meant for something different?

@fejta Three things come up for consistency.

  1. We have issues with contributor experience. If we have a consistent experience that's hard that won't help.
  2. How many people move from repo to repo? How much moving around is there? Is it a core group of people or most people? Have we looked at how much of a deal that is? Without knowing that how can we prioritize it.
  3. Consistency doesn't allow for innovation. If everyone needs to use the same tooling how can someone go innovate a better way to do something? The first mover wins. Look at Netflix. They don't enforce tools. Instead it's self service. Someone can go their own route and those someones become the new self-service options.

@stevekuznetsov As I understand it, the tooling parts were added after the steering committee reached conclusions in that doc. That was an addition after the fact.

In any case, because some group concluded it is not a good justification. People should be able to answer my original questions in a positive way for people.

And, we should be able to go back and audit the conclusions and reasons for what the steering committee went with later. Things change and those things may not apply later.

Member

mattfarina commented Jan 11, 2018

@jberkus why would everything use the general release process? For example, there is talk of moving kubectl out of k8s and having an independent release process and timing from k8s. It would decouple them. What benefit would kubectl have to use the general release process meant for something different?

@fejta Three things come up for consistency.

  1. We have issues with contributor experience. If we have a consistent experience that's hard that won't help.
  2. How many people move from repo to repo? How much moving around is there? Is it a core group of people or most people? Have we looked at how much of a deal that is? Without knowing that how can we prioritize it.
  3. Consistency doesn't allow for innovation. If everyone needs to use the same tooling how can someone go innovate a better way to do something? The first mover wins. Look at Netflix. They don't enforce tools. Instead it's self service. Someone can go their own route and those someones become the new self-service options.

@stevekuznetsov As I understand it, the tooling parts were added after the steering committee reached conclusions in that doc. That was an addition after the fact.

In any case, because some group concluded it is not a good justification. People should be able to answer my original questions in a positive way for people.

And, we should be able to go back and audit the conclusions and reasons for what the steering committee went with later. Things change and those things may not apply later.

@jberkus

This comment has been minimized.

Show comment
Hide comment
@jberkus

jberkus Jan 12, 2018

@mattfarina if the release process is completely decoupled and the subproject isn't interested in using the same release tools, then of course that doesn't apply. However, right now we have the opposite: several repos who do participate in the general release process but not with the same labelling or automation. That's why I'm saying that those two things need to be tied together.

jberkus commented Jan 12, 2018

@mattfarina if the release process is completely decoupled and the subproject isn't interested in using the same release tools, then of course that doesn't apply. However, right now we have the opposite: several repos who do participate in the general release process but not with the same labelling or automation. That's why I'm saying that those two things need to be tied together.

@fejta-bot

This comment has been minimized.

Show comment
Hide comment
@fejta-bot

fejta-bot Apr 24, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot commented Apr 24, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@fejta-bot

This comment has been minimized.

Show comment
Hide comment
@fejta-bot

fejta-bot May 24, 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

fejta-bot commented May 24, 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

@BenTheElder

This comment has been minimized.

Show comment
Hide comment
@BenTheElder

BenTheElder May 24, 2018

Member
Member

BenTheElder commented May 24, 2018

@cblecker

This comment has been minimized.

Show comment
Hide comment
@cblecker

cblecker May 29, 2018

Member

/remove-lifecycle rotten

Member

cblecker commented May 29, 2018

/remove-lifecycle rotten

@BenTheElder

This comment has been minimized.

Show comment
Hide comment
@BenTheElder

BenTheElder May 29, 2018

Member

thanks @cblecker. for anyone following along, @spiffxp is still on this but is on extended OOO. I imagine he'll continue this when he gets back

Member

BenTheElder commented May 29, 2018

thanks @cblecker. for anyone following along, @spiffxp is still on this but is on extended OOO. I imagine he'll continue this when he gets back

@spiffxp

This comment has been minimized.

Show comment
Hide comment
@spiffxp

spiffxp Aug 14, 2018

Member

/lifecycle frozen
Yeah I'll update this at some point, need to include all repos across all orgs.

Member

spiffxp commented Aug 14, 2018

/lifecycle frozen
Yeah I'll update this at some point, need to include all repos across all orgs.

@spiffxp

This comment has been minimized.

Show comment
Hide comment
@spiffxp

spiffxp Aug 14, 2018

Member

Related, I'm making sure all repos have OWNERS files, which sets the stage for them to use /approve (and thus tide) kubernetes/community#1721

Member

spiffxp commented Aug 14, 2018

Related, I'm making sure all repos have OWNERS files, which sets the stage for them to use /approve (and thus tide) kubernetes/community#1721

@spiffxp

This comment has been minimized.

Show comment
Hide comment
@spiffxp

spiffxp Aug 14, 2018

Member

Related, I'm making sure all repos live inside of sigs.yaml in one for or another. I anticipate this can help us head towards a sig-driven peribolos config kubernetes/community#2464

Member

spiffxp commented Aug 14, 2018

Related, I'm making sure all repos live inside of sigs.yaml in one for or another. I anticipate this can help us head towards a sig-driven peribolos config kubernetes/community#2464

@stevekuznetsov

This comment has been minimized.

Show comment
Hide comment
@stevekuznetsov

stevekuznetsov Aug 14, 2018

Contributor

tide doesn't require /approve FWIW, do all repos need it?

Contributor

stevekuznetsov commented Aug 14, 2018

tide doesn't require /approve FWIW, do all repos need it?

@spiffxp

This comment has been minimized.

Show comment
Hide comment
@spiffxp

spiffxp Aug 14, 2018

Member

True, I guess the reason I use it as a precondition is that any org member can /lgtm, while the use of /approve ensures there aren't drive-by merges

Member

spiffxp commented Aug 14, 2018

True, I guess the reason I use it as a precondition is that any org member can /lgtm, while the use of /approve ensures there aren't drive-by merges

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment