Should we turn down sending email to commits list (or turn down the lists entirely)

Project Infrastructure
,
1

@tstellar since you might be more up on all the infrastructure things than I am…

Back in the day we used to use the -commits list for post-commit (& even precommit) review with just replies to the commit emails.

These days, I think that probably hasn’t scaled, and especially with more git/github centric workflows, I imagine just replying to a random commit email on the list is unlikely to get noticed.

llvm-bugs@, on the other hand is setup as notify-only, and no one (except the bot) can email that list.

Should we move the *-commits lists to do the same? (at least clang and llvm?)

Should we just remove the lists entirely, and people can subscribe through github directly?

1 Like
2

I wouldn’t mind that - that makes it clearer that people in general won’t notice feedback that way.

I’d prefer not to. I subscribe to the lists, to get an overview of things that are going on, to pick up on reviews I might be interested in, without directly being subscribed.

That makes a nice distinction between threads I’m actively subscribed to and involved in, and a separate flow of notifications that I just casually browse.

3

I think this makes sense, we should be able to query the archives to see how many people actually email the list. My guess is that it is extremely low.

4

Would there be a way to get that distinction via some of the github email headers and rules?

Like I think github uses mention@noreply.github.com when sending email that mentions you - maybe there’s some other things like that that’d help distinguish the different email reasons?

yeah, there’s some differentiations:

For an email that’s triggered from just “watching” activity in the repo, it looks like:

From: llvmbot <notifications@github.com>
Reply-To: "llvm/llvm-project" <reply+AE5QSAI6HHV44I2R4FGYGPWEV73NVEVBNHHJCBFOGE@reply.github.com>
To: "llvm/llvm-project" <llvm-project@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>

For a comment on an issue that’s labeled with a label I’m in the team for:

From: llvmbot <notifications@github.com>
Reply-To: "llvm/llvm-project" <reply+AE5QSAN7AZ5IDHPYCL3MUHWEV25BBEVBNHHJBZ5FSA@reply.github.com>
To: "llvm/llvm-project" <llvm-project@noreply.github.com>
Cc: David Blaikie <dblaikie@gmail.com>, Team mention <team_mention@noreply.github.com>

And then for something where I’ve been mentioned:

From: bd1976bris <notifications@github.com>
Reply-To: "llvm/llvm-project" <reply+AE5QSAN4WUJP5Z5XGW5QNSGEUA5WTEVBNHHH7L3LGY@reply.github.com>
To: "llvm/llvm-project" <llvm-project@noreply.github.com>
Cc: David Blaikie <dblaikie@gmail.com>, Mention <mention@noreply.github.com>
5

(oh, I should say - instead of email based post-commit review, today most of it happens on PRs even after they’re committed, or can happen as github comments on the commit revision itself (& maybe directly on the source itself?))

I probably wouldn’t mind maybe having some conventions around whether we should use the PR or the commit - but I don’t think it’s /super/ harmful that that’s not entirely explicit. I think most folks have a rough sense of using the PR when it’s fresh, and maybe using the commit if they’re commenting on the change after a long period/through revision history, etc.

6

@tstellar thoughts on removing them entirely in favor of github features?

7

We should do post-commit review on the PR, because commit authors won’t get a notification when someone comments on their commit, but they will for a PR.

I think if we can provide similar functionality using GitHub notifications + mail filters, then I would be fine turning them off completely. For me, this has been working fine, but I’m not sure if this covers everyone’s use case.

8

I’m not sure about the exact circumstances/settings, but I definitely seem to get notifications for when people comment on my commits.

9

@boomanaiden154-1 Are you subscribed to all notifications? Are the notifications you get from comments on commits filterable in any way?

10

I’m not subscribed to all notifications. I’m only watching one issue label. I’m not sure if they’re filterable. I’ve never bothered to look given I’ve only gotten a handful of comments on my commits ever.

11

@boomanaiden154-1 helped me test this and the notification I got from a comment on my commit had my email address, and also Author <author@noreply.github.com> in the CC field. I don’t remember seeing Author before, but maybe I was testing it wrong.

So, it seems like at least the author gets notified on comments on their commits. However, I still think commenting on PRs is better, because than reviewers and assignees will get notified too.

12

I think that could work for setting up similar distinction/filtering, yes. But - if one were to watch the whole repo that way, there’s probably no easy way to do it on a subproject basis? I currently follow a couple of the major commits lists, but not e.g. the MLIR/Flang ones.

Secondly - I believe the commits lists archives also serve as a good event archive for the code reviews etc, I thought that was one of their intended purposes as well?

13

It is added to notifications from PRs and issues you created.

14

It looks like github has implemented some improvements recently to make the mails easier to sort:

15

I find the llvm-commits mailing list useful to get emails for all commits (for potential post-commit review of things that did not go through PRs). To the best of my knowledge, GitHub currently doesn’t offer any functionality to get email notifications for commits.

It would be great if llvm-commits would only send mail for commits, but not pull requests. Filtering out the pull requests mails is easy enough, but the current email infrastructure does not seem capable of keeping up with the amount of noise they generate. For me at least, llvm-commits mails often arrive in batches with very large delays.

1 Like
16

This is probably due to rate-limiting at a mail provider side…

17

That’s possible as well. The provider here is Fastmail. Per Account limits – Fastmail the limit on received emails is 8000 per day, plus the following:

In addition to the daily limits, there is a per-minute limit of 100 messages and 100 MB. This limit is the same for all account levels and is to stop large email floods from overloading an account.

We also have limits for the number of received messages from a single sender. No mail being received from a single sender can exceed half of your per-day or per-minute allowance. This limit is in place to stop an automated system from accidentally flooding your account, which would then prevent other email addressed to you from being received.

The PR notifications on llvm-commits might fall afoul of the per-minute limit maybe? Though I still wouldn’t expect hour-long delivery delays from that.

In either case, having llvm-commits be only commits would avoid the problem in any case, independently of which side it is on.

18

Maybe. We can check the sender logs to see what is going on. Sometimes there are also global per-sender limit, and usually these are the limits we’re hitting.

1 Like
19

I would strongly prefer we keep the llvm-commit’s list. I regularly use it to monitor what is going on in the project as a whole, and semi-regularly reply to reviews (mostly on github these days) with post commit feedback. I, reluctantly, agree that the list could be made read only. The lack of emails associated with commits means that the usually “send directly to author, CC list” tactic doesn’t work any more.

For my use case at least, I only use the commit notifications. Following the github transition, we start sending a bunch of other notifications to the list. I initially tried to use that, but in practice, they’re all being filtered to a folder I haven’t looked at in six months. I’d happily see those disabled.

20

I also subscribe to llvm-commits and cfe-commits in order to keep an eye on things and notice patches of interest.