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/05ddce3b88cfe9729811c4ce843c8ccbe6ab34b7/changelog.d/config)

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.






Attachment: signature.asc
Description: PGP signature

_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to