Translate 2019-03-07-raw-block-volume-support-to-beta.md

[yixin21]

zh-trans 2019-03-07-raw-block-volume-support-to-beta.md

ref:k8smeetup/website-tasks#3218

[yixin21]

/assign @chenrui333

[netlify]

Deploy preview for kubernetes-io-master-staging ready!

Built with commit 86ad15e

https://deploy-preview-23060--kubernetes-io-master-staging.netlify.app

[markthink]

/lgtm
/approve

[tengqm]

/lgtm
/approve
/tide-merge-method squash

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: markthink, tengqm

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• content/zh/OWNERS [tengqm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[idealhack]

/tide-merge-method squash

@tengqm it seems this command does not exist , you need to add the label manually.

[tengqm]

@idalhack I didn't get an error on that.

[idealhack]

yeah, there will be no errors because the bot treated that as a normal line instead of a command, but the result is no labels applied, and tide merged this PR using merge method, instead of your preferred squashing method, you can see all the commits on the master branch.

[tengqm]

@idealhack Just checked the git log, you are right.
I'm afraid we need to revert this and merge it again.
18 commits for this is terrible.

[tengqm]

I'm confused ... how can we fix this problem? The author was lazy when revising the PR. He/she was probably doing this revision in browser rather than from his/her git clone. If we revert this, we will create a new commit.

[idealhack]

I think it's OK to let it be now, as we probably don't want to force push to master. If we revert the change, the 18 commits won't go anywhere.

Could you check if you are able to apply labels to PRs manually? You'll need write access to the repo for that.

If you have the ability, please use it from now on, otherwise, please ask future PR authors to rebase locally and force push before merge.

[idealhack]

I'd also make a note to other approvers in SIG docs, as I see this is not a single case. It would be great if you can make a note in the next SIG docs meeting.

[idealhack]

Never mind, I found the right command, it's /label tide/merge-method-squash, please use it from now on and make a note to the SIG.

[jimangel]

@tengqm @idealhack is correct, you can use the label /label tide/merge-method-squash in the future (my reference cheat: https://kubernetes.io/docs/contribute/participate/pr-wranglers/#helpful-prow-commands-for-wranglers).

While it is unfortunate that this merged without a squash, I think it's better to leave it vs. creating additional commits or force rewriting history.

CC'ing tech leads for awareness (and comments if they disagree 😄 ): @kbhawkey @onlydole @sftim

[kbhawkey]

@tengqm @idealhack is correct, you can use the label /label tide/merge-method-squash in the future (my reference cheat: https://kubernetes.io/docs/contribute/participate/pr-wranglers/#helpful-prow-commands-for-wranglers).

While it is unfortunate that this merged without a squash, I think it's better to leave it vs. creating additional commits or force rewriting history.

CC'ing tech leads for awareness (and comments if they disagree 😄 ): @kbhawkey @onlydole @sftim

Hi. Yes, at this point it seems like the best option is to leave the multiple commits (as long as the Blog page builds 😃 ).

When I review a PR, I compare the number of files changed against the number of commits.

If the number of commits is greater than the number of files changed, I start to look for why the commits are needed.
I hold off of approving any PRs where the ratio is higher for the number commits.
Ideally, I prefer to have one commit per PR (or at the most 2 commts).
Perhaps we could use an automatic warning label from the bot
that alerts reviewers about the number of commits (some percentage of num commits to num files changed)?

[sftim]

I'd leave it, yep.

Also even if you set the correct label, things can race. Better to set that label in one comment and then add a second comment to LGTM or approve, after the label is added.

[tengqm]

Thanks for the feedbacks. I apologize for this incident. I was trying to save everyone's time by leveraging the automation. Obviously, the imagined prow command didn't work. It was not that I failed to notice that there are 18 commits. I did a bad thing by issuing a strange command to the bot and I hoped that the bot would say "command not recognized, try something else...". However, I got no error. Anyway, I learned something from this.