Replace the sendmail script about gh-migration

[warsaw]

I definitely use new-bugs-announce in my workflow.

[ericvsmith]

I also use new-bugs-announce in my workflow. It's how I know which new issues affect parts of the stdlib that I feel responsible for. I also use it for issues that don't relate to my code (so I'm not in CODEOWNERS), but where I can offer some help.

[asl]

Here is our solution: https://github.com/llvm/llvm-project/blob/main/.github/workflows/llvm-bugs.yml

[ewdurbin]

It seems the above workflow is ideal for new-bugs-announce, but I'd be very hesitant to implement a 1:1 send for the other list immediately. I'll get a PR set for the new-bugs-announce send now and add the credential for Mailgun so it can be merged when ready.

If someone else wants to consider how to handle feeding python-bugs-list, the Mailgun credential will be available :)

[ewdurbin]

See python/cpython#32421, which should work after merge.

[hugovk]

I'm getting the new-bugs-announce messages now. Thanks!

Is there any way we can get the sender to include the user's name, like worked before. Right now I only see "CPython Issues".

Not name, but something like this should work for username:

              const data = {
-               from: "CPython Issues <[email protected]>",
+               from: `${issue.data.login} <[email protected]>`,
                to: "[email protected]",
                subject: `[Issue ${issue.data.number}] ${issue.data.title}`,
                template: "new-github-issue",
                'o:tracking-clicks': 'no',
                'h:X-Mailgun-Variables': JSON.stringify(payload)
              };
              return mg.messages.create(DOMAIN, data)
            })
            .then(msg => console.log(msg));

We're already using issue.data.login in the payload:

              const payload = {
                author : issue.data.user.login,
                issue  : issue.data.number,
                title  : issue.data.title,
                url    : issue.data.html_url,
                labels : issue.data.labels.map(label => { return label.name }).join(", "),
                assignee : issue.data.assignees.map(assignee => { return assignee.login }),
                body   : issue.data.body
              };

Docs: https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#list-repository-issues

[ethanfurman]

I do use these two services to keep up to date with libraries I care about and issues I'm involved with.

[ned-deily]

Perhaps you can get information from the python.org mailman admin about how many users are subscribed to these lists. Posting in python-dev surely doesn't cover all users. Also be aware that the python-bugs mailing list is multiplexed into other forums, in particular to the gmane.comp.python.bugs newgroup provided by the news.gmane.io NNTP server which is how I usually access the list (and I do so regularly). By the nature of NNTP servers, it would likely be difficult to get an estimate of how many people read the list via that mechanism. (AFAIK, new-bugs-announce is not mirrored on gmane.) There are likely other ways to read the list on the web.

All that said, I could probably figure out a replacement workflow via GitHub notifications if needed but, as long as there is any activity on the existing Roundup-based b.p.o, I depend upon being able to see it.

[asl]

We (LLVM) were unable to find the ready replacement for this feature. So far we're thinking on utilizing the GitHub action that would trigger on new issue and send email to the mailing list. This is llvm/llvm-project#52605

[ewdurbin]

We have a mailgun account that's suitable as long as this will just be sending emails to distribution list on python.org!

Let me know what you need from me @ezio-melotti

[ericsnowcurrently]

I'm getting the new-bugs-announce messages now. Thanks!

Is there any way we can get the sender to include the user's name, like worked before. Right now I only see "CPython Issues".

What needs to be done to get python-bugs-list working again? (I already feel like I'm missing discussion on a number of issues that I was following but wasn't nosied. 😞)

[The-Compiler]

FWIW, I just got a mail from GitHub telling me that the workflow failed after I opened an issue:

python/cpython#93249
https://github.com/python/cpython/runs/6606492855?check_suite_focus=true

Due to:

[Error: Bad Request] {
  status: 400,
  details: 'Send options (parameters starting with o:, h:, or v:) are limited to 16 kB total'
}

I suppose it should truncate long issue bodies (there's a big C stacktrace hidden in a <details> in there). Should I open a separate issue for this? If so, in this repo, or in the CPython one?

[ezio-melotti]

Thanks for the report!

Should I open a separate issue for this? If so, in this repo, or in the CPython one?

A separate issue would be better, either in the CPython repo or in the core-workflow one.