@idryomov It's ready for your review, Ilya. Thanks for all your time and expertise today.

jenkins test api

@idryomov: I've made all of your suggested changes, and they're squashed into this commit now. I resolved all of the issues that were unambiguous and required no further consultation with you, but I've left a single issue open because I wasn't entirely sure that I had captured what you mean to say. Let me know what you think.

It looks like the last push ended up undoing (some of?) previous changes: --keyring still has =, etc in the current version.

@idryomov

It looks like the last push ended up undoing (some of?) previous changes: --keyring still has =, etc in the current version.

That's weird. Either I somehow missed this or a local working copy on one machine overwrote the changes I had pushed from the local working copy on the machine I use to attend CLT meetings. Anyway, it's fixed now. Good looking out, Ilya.

That's weird. Either I somehow missed this or a local working copy on one machine overwrote the changes I had pushed from the local working copy on the machine I use to attend CLT meetings. Anyway, it's fixed now. Good looking out, Ilya.

Everything but the = thing is still outstanding. I went ahead an unresolved the conversations that had been marked as resolved earlier (at least those that I could find), please go through them again, one by one.

A suggestion: I noticed that when you push an update, you always rebase as well, picking up unrelated changes. This makes it harder to review, both for you (am I force-pushing the right thing?) and for the reviewer (straight diff between between the old version and the new version doesn't cut it). I didn't mention this before to avoid overwhelming you with git-foo, but now that you got bitten: since force-pushing destroys history, default to keeping the base the same. Change the base only when it's actually needed, e.g. to pick up a dependency or resolve a conflict, and document that reason in the comment. Figuring out what went wrong and, more importantly, preventing such mishaps from happening in the first place becomes much easier then.

@idryomov:

That's weird. Either I somehow missed this or a local working copy on one machine overwrote the changes I had pushed from the local working copy on the machine I use to attend CLT meetings. Anyway, it's fixed now. Good looking out, Ilya.

Everything but the = thing is still outstanding. I went ahead an unresolved the conversations that had been marked as resolved earlier (at least those that I could find), please go through them again, one by one.

I have now whack-a-moled them and now I ping-pong this PR back to you.

A suggestion: I noticed that when you push an update, you always rebase as well, picking up unrelated changes. This makes it harder to review, both for you (am I force-pushing the right thing?) and for the reviewer (straight diff between between the old version and the new version doesn't cut it). I didn't mention this before to avoid overwhelming you with git-foo, but now that you got bitten: since force-pushing destroys history, default to keeping the base the same. Change the base only when it's actually needed, e.g. to pick up a dependency or resolve a conflict, and document that reason in the comment. Figuring out what went wrong and, more importantly, preventing such mishaps from happening in the first place becomes much easier then.

The docs workflow that we had settled on up to the time that we started refining the RBD-related English was developed to deal with those single-section revisions that ended up spamming everyone's inboxes. And when we were working with such small sections, a fixup-and-squash protocol for dealing with changes of the kind that we're dealing with in this PR never got confusing, because the texts we worked with were so brief that the lineage of the changes we made to them was orthogonal to our concerns. This is a long-winded and prolix way of saying: I see your point, and I think I've done something more accommodating now. I've just pushed a new commit without squashing it into the old commit. If this review passes muster, I'll squash these commits (after we get the approval of the RBD team) into a single commit and make a note to myself that this will be the new procedure for making these whole-rst-file-long documentation revisions.

I appreciate your patience in what must be a trying process.

@idryomov: Back at you.

#49484 - Quincy backport
#49485 - Pacific backport