Add changelog for v2.6.0rc1

[sloosvel]

Description

This PR adds the changelog for the first release candidate of v2.6

[codecov]

Codecov Report

Merging #1633 (ee237a2) into main (46f9c01) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1633   +/-   ##
=======================================
  Coverage   91.38%   91.38%           
=======================================
  Files         204      204           
  Lines       11173    11173           
=======================================
  Hits        10211    10211           
  Misses        962      962           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 46f9c01...ee237a2. Read the comment docs.

[zklaus]

This PR is not ready for review, much less for approval, and less still for merging since the checklist is not addressed.

[schlunma]

I disagree. I (as one of the previous release managers who is responsible for this kind of PRs) think this PR is fine to be merged.

The title is fine and the missing label will be noticed (at the latest) by Saskia when she creates the new changelog (I admit that I didn't check that, but this is something that can be adapted later).

Also, I was not aware that we have a review process of the review in place.

[zklaus]

While the verbiage for the ESMValTool is more explicit (

[The reviewer] looks at the list of files that were changed in the pull request and checks that all relevant checkboxes from the checklist in the pull request template have been added and ticked.

), the one for the core seems at least suggestive to me:

Please try to do everything on the list before requesting a review.

I think it's clear that no PR should be merged with unticked open items in the checklist; all items should be either ticked or removed. Ensuring that PRs for which the core team is responsible are in tip-top shape will encourage everyone else to stick to good practices too.

I don't think that "we can always fix this later" is a good argument to disregard the checklist. After all, the purpose of that is to streamline things and not to create more work down the line.

As for reviewing the review, I think everyone can comment where there seems to be a discrepancy between the published procedure and the procedure followed. As core team, we have perhaps a duty to do so.