Setup merge automation for all kubernetes repos #6227
Comments
k8s-ci-robot
added
area/prow
|
Why should all the repos have or use merge automation? What's the benefit for those that aren't using it today? |
@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 |
|
Benefit is a consistent experience between repos, which makes it easier to move around between them efficiently. |
|
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 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.
@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. |
|
@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. |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
k8s-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
k8s-ci-robot
added
lifecycle/rotten
|
/remove-lifecycle stale
…On Thu, May 24, 2018 at 2:41 PM fejta-bot ***@***.***> wrote:
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
<https://github.com/fejta>.
/lifecycle rotten
/remove-lifecycle stale
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6227 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4Bq6XQG37-ApCP4h0a441x5t3JJQRfks5t1yjzgaJpZM4RZ0xn>
.
|
|
/remove-lifecycle rotten |
k8s-ci-robot
removed
the
lifecycle/rotten
|
/lifecycle frozen |
k8s-ci-robot
added
the
lifecycle/frozen
|
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 |
|
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 |
|
|
|
True, I guess the reason I use it as a precondition is that any org member can |
|
/close |
|
@spiffxp: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/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:
Issues used to add repos in the past:
EDIT: as of 2018-09-17
[1] - staging repos live in kubernetes/kubernetes/staging and so use whatever merge automation kuberentes/kubernetes has
The text was updated successfully, but these errors were encountered: