Apply suggestions from code review

Co-authored-by: Grant Gainey <[email protected]>

docs/sections/blog/posts/2025/release_whenever.md

@@ -1,6 +1,6 @@
 ---
 date: 2025-01-03T00:00:00Z
-title: Whenever, Whatever based Release Cycle
+title: Whenever, Whatever-based Release Cycle
 author: Matthias Dellweg
 tags:
   - CI/CD
@@ -10,7 +10,7 @@ tags:
 
 "Release fast, release often!" is not a metaphor, it is a mantra.
 
-Pulp used to be a service mainly running on premises as part of products with extremely long release cycles.
+Pulp used to be a service mainly running on-premises as part of products with extremely long release cycles.
 About two years ago, we heard rumors to add highly volatile cloud service style installations to the mix.
 Because releasing a new version of pulpcore or any of its many plugins was a herculean task, the rumors were accompanied by very concerning sentences like:
 _"We will run this service off of main branches of all the plugins."_
@@ -43,15 +43,15 @@ They asked exactly the right questions and let me shatter a fair amount of unspo
 Fast forward to now, they have fully adopted the idea and actively supported the effort to ultimate success.
 
 But to set the stage right, we didn't start from nothing.
-Our project ecosystem already had the so called plugin template, that helps us to keep all the CI/CD infrastructure in a dozent of git repositories in sync.
+Our project ecosystem already had the so called plugin template, that helps us to keep all the CI/CD infrastructure in a dozen git repositories in sync.
 Also a huge amount of work has been done to turn the manual half a day per version release process into a completely automated one.
 
 So standing on the shoulders of these giants, we needed to adjust the following things:
 
 - Pull requests against plugins must be developed against the last released version of pulpcore, as you would do with any other library.
-    - Not only do we not use the main branch of pulpcore in a plugins CI anymore, but also stopped using the `Required-PR` feature that, for the benefit to run against uncommitted changes, required fragile coordination of merges spanning multiple repositories.
+    - Not only do we not use the main branch of pulpcore in a plugin's CI anymore, but also stopped using the `Required-PR` feature that, for the benefit to run against uncommitted changes, required fragile coordination of merges spanning multiple repositories.
     - In fact, this policy forces us to better coordinate the deprecation schedules for breaking changes and make sure other changes are additive in nature.
-- Since `pulp_file` and `pulp_certguard` are poster childs for `pulpcore` tests having a circular test dependency, these three components were merged into a single repository.
+- Since `pulp_file` and `pulp_certguard` are poster children for `pulpcore` tests having a circular test dependency, these three components were merged into a single repository.
 - All tests must be run on pull requests (for code changes) and nightly on main (for unexpected changes in the environment).
     - Performance tests are the exception here, because developer experience is very important too.
 - The criterion for inclusion in the main branch must be "shippable". No dependencies on unreleased code are allowed. The pull request review therefore is the last gate to inclusion in the next release.
@@ -64,7 +64,7 @@ So standing on the shoulders of these giants, we needed to adjust the following
 - The results of the nightlies must be made aware to the team. Being red must lead to an all hands on deck call.
 
 The most astonishing side effect in all of this is, when we realized, we stopped spending about six engineer hours per week in a crowded meeting on discussing whether performing the next release is worth doing or we should delay once more.
-We now simply release a new y-Release of Pulpcore every tuesday given a feature is pending in main, and a z-Release on all the supported branches that recieved any backports or dependency updates.
+We now simply release a new Y-release of Pulpcore every Tuesday given a feature is pending in main, and a Z-release on all the supported branches that received any backports or dependency updates.
 We can also release a new bugfix release at any time if asked to do so.
 Another sign of the team fully supporting the idea is the prompt contribution of a `check_release` script to replace the manual examination of these conditions.
 We even automated preparing a new release branch (y-stream) and managing the patchback-labels for supported branches.
@@ -81,7 +81,7 @@ Also we still allow ourselves to delay a breaking change release (recurring ever
 Nothing comes for free though.
 The fact that we produce so many y-Releases now made it an absolute necessity to reduce the number of supported release branches.
 But we managed to negotiate with our downstream products that we keep a small set of them alive for their lifetime in a supported product.
-The ones inbetween are simply abandoned.
+The ones in between are simply abandoned.
 
 Once again I want to express a heartfelt thank you to my team, including management, and end with reciting two very reassuring, quoteworthy and related phases I came accross on the way: