Upcoming fork for GHC 10.0, new changelog system for GHC 10.1
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.
Hi all, Marge bot is temporarily paused until the GHC 10.0/10.1 fork. Reminder to rebase your MRs after the fork, as changelog entries will now be required for MRs. I will update you when the fork is complete and Marge bot is operational again. Thanks, Zubin On 26/04/03 20:59, Zubin Duggal wrote:
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.
Hi all, haskell.org has been affected by some SSL certificate issue, which is preventing CI from passing for the fork/bump. Marge bot is still paused, I will update you on when it is back up. Thanks, Zubin. On 26/04/09 14:50, Zubin Duggal wrote:
Hi all,
Marge bot is temporarily paused until the GHC 10.0/10.1 fork.
Reminder to rebase your MRs after the fork, as changelog entries will now be required for MRs.
I will update you when the fork is complete and Marge bot is operational again.
Thanks, Zubin
On 26/04/03 20:59, Zubin Duggal wrote:
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.
The GHC 10.0 fork is now completed and Marge bot is now re-enabled. However, please make sure to rebase your branch and add a changelog entry in changelog.d/ as described in https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing/changelog before assigning MRs to Marge bot. Since branches based on old master commits don't have the new lint-changelog job, such branches will not fail CI due to missing or misformatted changelog entries. Once WIP MR branches rebase on master, this will not be possible anymore. As part our efforts to ship a more complete and comphrensive release notes for the next major release, we would appreciate cooperation in not assigning Marge for MRs that don't have a changelog and make user visible changes. If your MR truly does not need a changelog entry, label it 'no-changelog'. Thanks, Zubin. On 26/04/10 13:46, Zubin Duggal wrote:
Hi all,
haskell.org has been affected by some SSL certificate issue, which is preventing CI from passing for the fork/bump.
Marge bot is still paused, I will update you on when it is back up.
Thanks, Zubin.
On 26/04/09 14:50, Zubin Duggal wrote:
Hi all,
Marge bot is temporarily paused until the GHC 10.0/10.1 fork.
Reminder to rebase your MRs after the fork, as changelog entries will now be required for MRs.
I will update you when the fork is complete and Marge bot is operational again.
Thanks, Zubin
On 26/04/03 20:59, Zubin Duggal wrote:
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.
participants (1)
-
Zubin Duggal