Skip to content
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

Changed merge policy #6050

Merged
merged 1 commit into from
Apr 2, 2015
Merged

Changed merge policy #6050

merged 1 commit into from
Apr 2, 2015

Conversation

piosz
Copy link
Member

@piosz piosz commented Mar 27, 2015

@zmerlynn
Copy link
Member

Just to be clear, are we saying that merges are now a 24/5 free-for all with no core hours, as long as they've simmered for 2 hours? Or that people can only merge when it's daylight relative to them? (Which is super confusing because it's 6am here and core hours in Poland right now.)

@zmerlynn
Copy link
Member

(The "business day" language threw me off. I'm assuming that just means M-F and isn't related to hours.)

@piosz
Copy link
Member Author

piosz commented Mar 27, 2015

@zmerlynn In my opinion the first option is better as long as merger will be available for some time to fix possible problem. Let's see what other folks think.

"business day" means M-F excepting holidays. If you think there is a better word, I won't argue.

@zmerlynn
Copy link
Member

Nah, I'm happy with 24/5. Y'all have also been pretty carefully watching
Jenkins, which makes me happy.

Business Day is fine. "Monday-Friday" would be precise and simple, too.
On Mar 27, 2015 6:34 AM, "Piotr Szczesniak" notifications@github.com
wrote:

@zmerlynn https://github.com/zmerlynn In my opinion the first option is
better as long as merger will be available for some time to fix possible
problem. Let's see what other folks think.

"business day" means M-F excepting holidays. If you think there is a
better word, I won't argue.


Reply to this email directly or view it on GitHub
#6050 (comment)
.

## Code reviews

All changes must be code reviewed. For non-maintainers this is obvious, since you can't commit anyway. But even for maintainers, we want all changes to get at least one review, preferably from someone who knows the areas the change touches. For non-trivial changes we may want two reviewers. The primary reviewer will make this decision and nominate a second reviewer, if needed. Except for trivial changes, PRs should sit for at least 2 hours to allow for wider review.
All changes must be code reviewed. For non-maintainers this is obvious, since you can't commit anyway. But even for maintainers, we want all changes to get at least one review, preferably (for non-trivial changes obligately) from someone who knows the areas the change touches. For non-trivial changes we may want two reviewers. The primary reviewer will make this decision and nominate a second reviewer, if needed. Except for trivial changes, PRs should sit for at least 2 hours to allow for wider review.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Propose to strike the "at least 2 hours" language and replace with

Except for trivial changes, PRs should not be committed until relevant parties (e.g. owners of the subsystem affected by the PR) have had a reasonable chance to review them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@thockin
Copy link
Member

thockin commented Mar 27, 2015

Let's de-emphasize exact times and instead focus on intent - relevant parties must sign off on important PRs. The less complex the PR, the less the rules matter. Nobody should be merging on their own nights and weekends. Nobody should be merging without giving people a reasonable shot at review.

@brendandburns
Copy link
Contributor

Yeah, I'd summarize the intent "Relevant parties should have the opportunity to look at a PR in their local business hours" or some such. The goal is that no one feel they need to check the open PR list at all hours.

Can you add a sentence at the start to indicate something along these lines?

Thanks!
--brendan

@brendandburns
Copy link
Contributor

LGTM. Will merge during business hours. (or feel free to do the same ;)

@brendandburns brendandburns added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 2, 2015
jszczepkowski added a commit that referenced this pull request Apr 2, 2015
@jszczepkowski jszczepkowski merged commit 860257e into kubernetes:master Apr 2, 2015
@piosz piosz deleted the docs branch April 29, 2015 08:56
xingzhou pushed a commit to xingzhou/kubernetes that referenced this pull request Dec 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm "Looks good to me", indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants