Mailing List Archive: Questions, suggestions after doing the 5.39.5 release

[.I meant to write this up immediately after the release on Nov 20; I just
found my notes and remembered I'd forgotten!]

- In the porting docs, what's the difference between "Victims" (see
Porting/release_schedule.pod) and "The Keepers of the Pumpkin"
(pod/perltoc.pod)? The latter lists everyone who has done a blead, maint or
stable release, but what is the import of the former? Should these two
lists be consolidated?

- core porters: when reviewing a pull request, especially from a newbie,
please ensure that a perldelta entry is included, or consider writing one
yourself.

- when merging a pull request, please consider using the "merge" type -- it
groups commits from the pull request together, and provides a reference to
the PR. This is very useful later on when examining history, as it will
allow referencing the overall description of this group of changes, as well
as allowing access to discussion of these changes.

thank you!
-your erstwhile and occasional blead releaser

On Sun, Dec 17, 2023 at 3:29?AM Karen Etheridge <karen@froods.org> wrote:
>
> [.I meant to write this up immediately after the release on Nov 20; I just found my notes and remembered I'd forgotten!]
>
> - In the porting docs, what's the difference between "Victims" (see Porting/release_schedule.pod) and "The Keepers of the Pumpkin" (pod/perltoc.pod)? The latter lists everyone who has done a blead, maint or stable release, but what is the import of the former? Should these two lists be consolidated?

The "Victims" is a list of people who can be contacted to handle dev
releases. This isn't the same as the list of everyone who has done a
release. We should probably prune and update the Victims list though.
There are a number of people on it who are not active in perl
currently.

> - when merging a pull request, please consider using the "merge" type -- it groups commits from the pull request together, and provides a reference to the PR. This is very useful later on when examining history, as it will allow referencing the overall description of this group of changes, as well as allowing access to discussion of these changes.

Currently, pull requests on GitHub are configured to only allow
merging via rebase. While a rebase+merge would be preferable, GitHub
does not offer that feature. We could consider allowing merges on
GitHub rather than forcing a rebase, but this would result in a rather
messier history. It's possible to rebase a PR through the UI prior to
merging, but this can't be easily enforced, and requires the author of
the PR to allow it.