As far as I can see, your email address is readily available from many sources including preprint servers, published papers, etc. Nothing is moderated and hidden. And it is even available in much easier to digest format with explicit “mailto:” link, etc. So why code contributions are so special? Why can’t you use the very same email that is already exposed?
The e-mail that are published are either my e-mail address at my previous employer or a student e-mail address that is getting decommissioned soon that I had to put up to submit papers (and which I now regret making public for the reasons you rightfully mentioned before).
A simple example here, related to the relicensing effort: my commits are owned by Sony, as are those of other Sony employees. By me and my fellow colleagues using our Sony email addresses, people involved with LLVM can tell that those commits are owned by Sony, and therefore who to contact in the event of a need to contact the legal owners of commits (e.g. for relicensing purposes). If I change company, my previous commits will continue to be owned by Sony, so I’ll have no legal ability to agree to or otherwise to a relicensing of those commits, so contacting me on GitHub would not be of any use to LLVM. If I’d previously hidden my email address, it might become virtually impossible in the future to determine ownership of commits, should I no longer be contactable for some reason.
5 Likes
That makes a lot of sense. I think my concern are mostly related to independent contributors then, I think when one has a professional e-mail it’s easier to put it up.
I’m not going to comment anymore on this matter because it is starting to be unhealthily stressful. I really hope this gets resolved in a way that works for everyone.
I’ve just run into a situation where the contributor doesn’t want to set their email to be public because of their fears of spam, despite the new automated comment and me pointing it out. They stated that “it wasn’t a problem before” referring to a note by @JDevlieghere on a previous PR who said it was okay to use the noreply email.
This topic is causing confusion and conflict between different people. We REALLY need an agreement that is formally documented somewhere in the LLVM docs on the official stance. If the agreement is “no private emails”, then we should say so and point out how to change the setting. Does this need escalating to the formal decision-making process? Should it have Foundation input/direction (there are non-engineering concerns here apart from anything else)?
7 Likes
+1 I have similar situation. Since the patch is nice to have, but not super important I’m not sure whether I should accept the patch without an email address.
1 Like
Perhaps using the phraseology private e-mail is too harsh here. It is easy to misunderstand as LLVM wanting to intrude on their personal information by requiring a personal e-mail address. Instead, we should say that we want an e-mail address through which the author is reachable. (Given previous concerns that the GitHub auto-generated e-mail is not routing back to your actual e-mail address(es).)
So if someone does not want to “give up” their personal e-mail, it is also a solution that they register a secondary e-mail address, perhaps specifically for open-source contributions (maybe not just contributions to LLVM, but in general), and use that instead. The only truly needed “requirement” in this discussion is that the contributor regularly checks this e-mail that is used for contributions. (We could even link the appropriate documentation pages for the most widely used e-mail providers on how to set up automatic forwarding, IMAP pulling, etc.)
1 Like
It seems the current GitHub Action doesn’t pick up when some commits use a private email and some don’t. In the case of [Windows SEH] Fix crash on empty seh block by R-Goc · Pull Request #107031 · llvm/llvm-project · GitHub most of the commits (including the first one) used a real email address, but some of the later ones didn’t, but no comment was made by the bot to alert reviewers. Then when it was merged it silently ended up using the private email, which I only became aware of in the backport request I created on their behalf (release/19.x: [Windows SEH] Fix crash on empty seh block (#107031) by llvmbot · Pull Request #107466 · llvm/llvm-project · GitHub).
It seems the action did not run at all on that PR for some reason
Hm, so there’s [Windows SEH] Fix crash on empty seh block · llvm/llvm-project@24a7943 · GitHub that was never approved to run by a maintainer, but also the trigger for the job is PR creation, not further commits being added, so differs from the clang-format job.
This should also be added to the github user guide. I had no clue github even did this, nor that it could cause problems. I don’t recall ever setting this so I guess this is on by default. I also don’t really understand it as git signs commits with my email already. So github doing this has little point. And as for part of the commits being with the github email and part with mine, it’s because work done locally with git used my email, but everything done in github (codespace edit, accepting suggestion, rebase) used the github email address. From what I can see the action only runs when a PR is opened. So it wouldn’t trigger in my case the first time. The second time when the commit was with the github email it did trigger.
We could change it to a pull_request target so that it gets run everytime someone pushes to the PR. We aren’t going to be able to get around having a maintainer approve it without switching to pull_request_target though, which would bring along security concerns.
We could rewrite it to use the Github API and then use pull_request_target which wouldn’t have any security concerns. That shouldn’t be too difficult. I think just leaving it as a pull_request though would be best. There are other workflows that require maintainer approval, and they will only grow.
Making it actually run on every push to a pull request would be good though and would pop up a comment if there are issues, probably significantly increasing visibility. At some point, it would be nice to mandate these checks, but we’re a long way off from being able to do that, and that’s an entirely separate discussion.
FWIW, the actual email address within the commits doesn’t end up mattering here; when we merge PRs with squash and merge (the only option enabled for us), the commit author gets rewritten as the info of the github account of the PR author, even if the PR only consisted of one single commit. So the bot doesn’t need to check the individual commits of a PR (and doesn’t necessarily need to rerun after pushing more commits to the branch), it only needs to check the account setting for the author of the PR.
(It’s of course possible that the user had it set to public first when opening the PR, and then changing the status before the PR is ready to be merged.)
If the email address is being rewritten that may come as a surprise to people, and could cause issues with employers that want their company’s email address to be used for authorship, so likely needs documenting.
According to github documentation for any web-based operations the email will be rewritten to the primary email set in Github, which will be noreply if keep my email private is set. There is no way to set settings per repo. A thread about it was opened 3 years ago in community discussions but went nowhere. On the other hand there is even a setting to block pushes with a private email. Link to docs.
I’d like to express strong support for requiring the following information in LLVM commit messages:
- A valid email address (valid at the time of contribution),
- The contributor’s real name (rather than a GitHub handle), so it’s clear who is making the contribution.
In general, I believe contributors should:
- Make it easy to contact them (*), especially when someone needs to discuss their commits.
- Be open and transparent about their identities, both online and offline.
Currently, the absence of clear guidelines on this front can create challenges. For example, here’s a recent commit in MLIR:
commit 08efa23083606dc0248c4a7dee7087fa96b29c04
Author: Max191 <44243577+Max191@users.noreply.github.com>
[mlir] Allow multi-result ops in reshape fusion (#108576)
If I want to reach out to the author, I would need to use GitHub, which may not always be ideal. Additionally, in this case, the author’s GitHub profile (Max191 · GitHub) doesn’t provide much useful information, making it harder to communicate effectively.
I also believe it would benefit the project to rely less on GitHub and lean more toward standard Git workflows (where practical). GitHub handles can be changed, abandoned, or deleted, while real names are generally more stable over time 
-Andrzej
(*) Providing a valid e-mail address would qualify.
2 Likes
I think Aaron recently sent a PR to commit the policy change, and I think the consensus on the thread here is that contributors should provide an email that can be reached to allow direct, private communication off of GitHub, to handle issues like normal breakage, IP concerns, or, as is recently relevant, governance processes.
The contributor’s real name (rather than a GitHub handle)
I think the long-standing de facto project policy has been to allow pseudonymous contributions, so this would be a significant change. I think the community would benefit from taking this use case a bit more head-on, and documenting best practices for such contributors. Really what the community needs is an email that lives long enough so the community can follow up with contributors over a reasonable time horizon. I think there does come a point where contributors may wish to “retire” and not be contacted about their work anymore, and that seems reasonable.
If I were to reopen this topic, I think it would be worth documenting some kind of “time to live”, like how durable does the email have to be, or if I use an employers email and change jobs, how do we expect folks to update their contact info so folks can reach them off github in the future. But, let’s call that future work and do one policy update at a time.
1 Like
LLVM does have a .mailmap file; only ~25 entries. But we should lean more on that as folks’ email addresses change over time.
What if i have private primary email on github, but use separate public email to commit changes, so my commits will have Co-authored-by: my_public_email, so i will be reachable via it?
I’m not sure how that is possible, @klensy. If you commit your own change from a PR, you can select which e-mail address you want to have associated with the Author: field from a drop-down of verified e-mail addresses associated with your GitHub account. The Committer: field will be GitHub @web-flow and have a GPG signature of GitHub attached. If you commit outside of GitHub, then the Co-Authored-By: lines need to be filled manually. Nevertheless, those commits you put up as part of a PR are individually addressable, and each will have an Author: and Committer: fields set depending on the configuration of the machine/user on which the commit was made.