Address some PR comments

release notes/v0.27.0.md

@@ -16,14 +16,14 @@ See the [documentation](https://k6.io/docs/using-k6/executors) for details and e
 
 Some of the currently possible scenarios were formalized into standalone executors:
 
-- Shared iterations: a fixed number of iterations are "shared" by all VUs, and the test ends once all iterations are executed. This scenario was possible with the previous `vus` and `iterations` options.
-- Constant VUs: a fixed number of VUs execute as many iterations as possible for a specified amount of time. This scenario was possible with the previous `vus` and `duration` options.
-- Ramping VUs: a variable number of VUs execute as many iterations as possible for a specified amount of time. This scenario was possible with the previous `stages` option.
+- Shared iterations: a fixed number of iterations are "shared" by all VUs, and the test ends once all iterations are executed. This executor is equivalent to the global `vus` and `iterations` options.
+- Constant VUs: a fixed number of VUs execute as many iterations as possible for a specified amount of time. This executor is equivalent to the global `vus` and `duration` options.
+- Ramping VUs: a variable number of VUs execute as many iterations as possible for a specified amount of time. This executor is equivalent to the global `stages` option.
 - Externally controlled: control and scale execution at runtime via k6's REST API or the CLI.
 
 And new executors were added to support some of the most frequently requested scenarios that were previously difficult or impossible to model:
 
-- Per VU iterations: each VU executes a fixed number of iterations.
+- Per VU iterations: each VU executes a fixed number of iterations (#381).
 - Constant arrival rate: a fixed number of iterations are executed in a specified period of time. This allows k6 to dynamically change the amount of VUs during a test run to achieve the specified amount of iterations per period, which is useful for a more accurate representation of RPS, for example. See #550 for details.
 - Ramping arrival rate: a variable number of iterations are executed in a specified period of time. This is similar to the ramping VUs executor, but for iterations instead.
 
@@ -32,9 +32,9 @@ And new executors were added to support some of the most frequently requested sc
 - Several executors can be configured in a single test run, both sequentially and in parallel (closes #239).
 - Each executor has a `startTime` property, which defines at what time relative to the test run start it will start executing.
 - Executors have a new `gracefulStop` property that allows for iterations to complete gracefully for some amount of time after the normal executor duration is over (closes #879); even with `gracefulStop=0`, i.e. the old behavior, metrics are emitted and processed in a much saner way (closes #1033).
-- The new `execution-segment` options allow easy partitioning of test runs across multiple k6 instances. Initially this applies to configuration options like number of VUs or iterations, but opens the door to test data partitioning, an often requested feature. See #997 for more details.
+- The new `--execution-segment` and `--execution-segment-sequence` options allow easy partitioning of test runs across multiple k6 instances. Initially this applies to configuration options like number of VUs or iterations, but opens the door to test data partitioning, an often requested feature. See #997 for more details.
 - Different executors can execute different functions other than the `default` exported one. This offers more flexibility for organizing your tests, building test suites, etc.
-- Different executors can have different environment variables or tags.
+- Different executors can have different environment variables and tags.
 
 
 ## UX
@@ -74,3 +74,7 @@ And new executors were added to support some of the most frequently requested sc
 - Tests with infinite duration are now only possible via the `externally-controlled` executor.
 
 - Previously, all iterations were interruptible - as soon as the specified `duration` expired, or when VUs were ramped down in a stage, any running iterations were interrupted. Now all executors besides the `externally-controlled` one have a `gracefulStop` period of `30s` by default (closes #898). Additionally, the `ramping-vus` executor has a `gracefulRampDown` parameter that configures the ramp-down grace period. For those periods, no new iterations will be started by the executors, but any currently running iterations will be allowed up to the specified periods to finish their execution.
+
+- k6 will now exit with an error if `--address` is specified but the API server is unable to start. Previously this would've resulted in a warning message.
+
+- The format returned by `Date.prototype.toUTCString()` was changed from `Thu Jan 01 1970 00:00:00 GMT+0000 (UTC)` to `Thu, 01 Jan 1970 00:00:00 GMT`. This is a fix that aligns it with the ECMAScript spec. See https://github.com/dop251/goja/issues/119 .