Storing email addresses in git is a very bad idea for legal compliance reasons. They count as PII for several privacy laws and so I believe a legal request to expunge them will require rewriting history of the git repo. This is the kind of thing I wouldn't want to do until after talking to a lawyer and I generally find that I can maximise my happiness by minimising my time spent talking to lawyers about compliance questions. Note that several lawyers have already written opinions about retaining the name / email in git commit messages after being asked to delete them and that situation is already quite complicated.
I don't really understand why they're needed here though. Gerald is sending GitHub notifications, users can configure these to forward to email addresses (and can even forward them to different email addresses for different projects, so that you can send work and personal project notifications to different email addresses, for example). If I'm subscribed to an issue / PR, I get an email for every new message. Reimplementing this sounds like a lot of effort for no gain.
Storing email addresses in git is a very bad idea for legal compliance
reasons. They count as PII for several privacy laws and so I believe a
legal request to expunge them will require rewriting history of the git
repo.
Fair point, I did not consider this. Github account names are also PII, right? So we should not store them in the repo either. That means we would need some sort of private database to store (and delete) all user-specific configuration information. So this would be a larger solution
I would only need the email addresses for commit notifications. As you said for Issues and Pull Requests we can use GitHubs own notification features. However if we want customizable notifications on commits, Github doesn’t really offer anything there and we would have to implement the feature ourselves.
I found one app that does notifications on commits and they also need email addresses: https://app.github-file-watcher.com/
So maybe we don’t have to implement that at all and point our users to that service. I just signed up for their service to try it out.
(replying to my initial email because the thread seems to have gone off on a tangent)
A long term plan on what to do (migrate to github PRs? Something else?) is important, but let’s not get lost in the weeds: we have breakages with phabricator today. I think it’s important to not let our daily workflows degrade while we argue about what to do next. Minimally, we could fork phabricator into the LLVM project and fix the arcanist breakage. I don’t think maintaining a fork long term is a good idea, especially since phorge exists. We should not advertise our fork as being “maintained” to anybody, aside from the minimal goal of keeping existing workflows for LLVM functional while we decide on a migration plan.
My personal opinion on the topic of “using phabricator vs github PRs” is to stick with phabricator. I personally prefer the “push patch sets, then merge a patch into the tree” approach to the github “fork the repo, push some changes to your fork, then merge your fork with upstream”. I occasionally commit to CMake (which uses gitlab), and always find the experience quite confusing and awkward. I don’t know much about Phorge, but if it’s a Phabricator clone, and is actually being maintained, it seems to me to be a good migration target. I would also personally be fine with using Gerrit.
