Fix errors in change log

[hbushouse]

While composing the public release notes for B9.2 I noticed a number of errors in the change log. Some were dramatic (e.g. changes being listed under the wrong release version), while others are just updates for clarity and grammar.

Checklist for maintainers

• added entry in CHANGES.rst within the relevant release section
• updated or added relevant tests
• updated relevant documentation
• added relevant milestone
• added relevant label(s)
• ran regression tests, post a link to the Jenkins job below.
  How to run regression tests on a PR
• Make sure the JIRA ticket is resolved properly

[zacharyburnett]

I assume the entries under the wrong version are from PRs that lived through several releases; I'll look into improving the change log checker to also check if the entry is under the latest version

[zacharyburnett]

LGTM

[hbushouse]

I assume the entries under the wrong version are from PRs that lived through several releases; I'll look into improving the change log checker to also check if the entry is under the latest version

That's correct. Sometimes a PR branch sits around long enough that a release happens before the PR finally gets merged, so the entry is then in the wrong section of the log. I guess it would also help if we (as reviewers) make sure that in those situations the PR branch gets rebased, which might automatically fix the location of the log entries. Or if not, we just need to manually check and fix before approving.

[zacharyburnett]

https://github.com/spacetelescope/jwst/actions/runs/4872232055/attempts/1#summary-13202639430

E       assert 614.6205830574036 < 600

is this expected with MacOS?

[hbushouse]

That's an execution time test, to alert us when a step or algorithm suddenly takes much longer to execute than before, and I often see those failures in the Mac tests, just because whatever Mac server/system is being used is way slower than our Linux test system (we see the same thing with regression tests - they take like 2x longer on Mac than Linux).

[zacharyburnett]

oof, GitHub must really be stretching their Mac licenses thin with processor allocation. I guess we can't complain about free CI time, though. Hopefully Boyle will be more stable in the future as well