Re: Dealing with corporate email recycling

From: Sean Allred <allred.sean@gmail.com>
Date: Mar 13, 2022, 22:40 UTC
Message-ID: <87ilsha2b7.fsf@gmail.com>
In-Reply-To: <f6ecca05-b669-0e36-302f-a6113571ac12@iee.email>

Philip Oakley <philipoakley@iee.email> writes:

Show 5 quoted lines

> The GDPR isn't as onerous as some suggest, as it isn't a set of black
> and white rules, rather in cases like these you need to have a real
> strong reason for why data is retained etc, such as being part of the
> verification and validation of the commit data. There have been various
> discussions around this in many of the technical journals.

That's good to hear that this has already been discussed in the community (though I'm hardly surprised now that you mention it -- I'm sure it was and remains a hot topic!).

Show 5 quoted lines

> It maybe that your internal Git version could disable the particular
> `format` option ('%ae'?) for the original name, so only the designated
> ('redacted') mailmap entry is shown to casual users (assumes the repo is
> inside the corporate firewall). This would avoid invalidating the repos
> validation capability, while meeting the needs of GDPR type regulations.

I do want to note that at present we're not primarily concerned with GDPR, but I am following up on that internally to see if there are any considerations we need to make. This is certainly an interesting tactic for repositories that are hosted in GDPR-effective states, though.

> In the same vein, a local Git version could, being open source, add
> allowances for your extra mailmap entry details, such as adding a post
> fix " % <approxidate>" limits for the use of the particular name/email
> combo to allow date ranges to emerge.

I'd prefer the ability to agree on a pattern and merge support for it upstream. This way, forges can pick up support, too. Bonus points if the forge doesn't necessarily have to do more work than it already does.

Your " % <approxidate>" suggestion sounds a lot like the 'Valid-Before/ Valid-After' proposal from my original post in this thread (admittedly not my idea). Is there a compelling reason to use this approach over UUIDs? I ask not to suggest there isn't a compelling reason, but mostly to make sure we consider the best arguments (and drawbacks) for any/all approaches.

> I noted that all the .mailmap examples in the man page have ">" as the
> final character, but I haven't looked to see if the code always requires
> that the last element of the entry is an <email> address, or whether it
> currently barfs on extra elements.

FYI mailmap does support comment syntax (starting with # through \n). It's worth noting that Ævar suggested earlier that perhaps we could "(ab)use the comment syntax". I tend to prefer their other approach, though:

    > I.e. we simply ignore things we can't map now, so one way to do it
    > is to start with something that produces an invalid (but harmless)
    > mapping to current readers, [...]

rather than use magic comments :-) Adapting to your suggestion, this might look like the following:

    A. U. Thor <foo@example.com> <ada.example.com> <[ approxidate ]>

Would be curious to know what other mailmap readers exist and how they would react to this.

-- Sean Allred