Hi all, We plan to fork for GHC 10.0 next week on Thursday (April 9th). Please make sure any merge requests you would like to see merged are merged in time for the fork. If the merge request is particularly important, and you are confident it is ready for a merge, please let me know by responding to this email, and I will do my best in trying to land it before the fork. If a merge request is still incomplete but fixes a critical bug we should fix in GHC 10.0, mark it with the backport needed:10.0 label and we will consider it for backporting. After the GHC 10.0 fork, master will be bumped to GHC 10.1. Any MRs that land after this point will require changelog entries, according to the scheme implemented in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15830 This will require all MRs, unless tagged with "no-changelog" label (reserved for entirely non user facing changes like CI), to populate an entry in the changelog.d/ directory. You will need to create a file with a descriptive name, based on your changes, for instance (picking a patch that recently landed): changelog.d/fix-datakindsinfix: ``` section: language synopsis: Fix a bug where GHC would erroneously accept infix promoted data constructors without enabling :extension:`DataKinds`. issues: #26737 mrs: !15609 description: { As a result, you may need to enable :extension:`DataKinds` in code that did not previously require it. } ``` The `section` field controls what section of the release notes your entry ends up in, available sections are defined in changelog.d/config (https://gitlab.haskell.org/ghc/ghc/-/blob/05ddce3b88cfe9729811c4ce843c8ccbe6...) The `synopsis` field is a brief description of the change. This is the main payload `issues` is a space seperated list of issues fixed by the change `mrs` is a space seperated list of mrs. If you are modifying a feature which already has a changelog entry, add your MR to the `mrs` list for the existing entry instead of creating a new changelog entry. `description` is an optional field where you can expand on the description of your change. It will be rendered on a new line following the `synopsis` entry in the changelog. Both `section` and `description` accept the existing RST syntax we use for release notes entries. A new CI job ensures that each patch (unless otherwise labeled) touches a properly formatted changelog file with an `mrs` field including the MR number of the patch. This job will not block subsequent build/validation jobs from running, but it will be needed to pass before Marge can pick up the MR for merging. If you have any questions or feedback about this system, now is the time to give it. It will be much easier adding any additional metadata we might want to track in changelog entries now, rather than after the fork. Thanks, Zubin.