Re: RFC: individual public-inbox/git activity feeds

[Daniel Borkmann <daniel@iogearbox.net>]

On 10/10/19 9:28 PM, Konstantin Ryabitsev wrote:
[...]
> # Individual developer feeds
> 
> Individual developers can begin providing their own public-inbox feeds.
> At the start, they can act as a sort of a "public sent-mail folder" -- a simple tool would monitor the local/IMAP "sent" folder and add any new mail it finds (sent to specific mailing lists) to the developer's local public-inbox instance. Every commit will be automatically signed and pushed out to a public remote.
> On the kernel.org side, we can collate these individual feeds and mirror them into an aggregated feeds repository, with a ref per individual developer, like so:
> 
> refs/feeds/gregkh/0/master
> refs/feeds/davem/0/master
> refs/feeds/davem/1/master
> ...
> 
> Already, this gives us the following perks:
> 
>   - cryptographic attestation
>   - patches that are guaranteed against mangling by MTA software
>   - guaranteed spam-free message delivery from all the important people
>   - permanent, attestable and distributable archive
> 
> (With time, we can teach kernel.org to act as an MTA bridge that sends actual mail to the mailing lists after we receive individual feed updates.)
[...]

[...]
>   - we still continue to largely rely on email and mailing lists, though    theoretically their use would become less important as more    developer feeds are aggregated and maintainer tools start to rely on    those as their primary source of truth. We can easily see a future    where vger.kernel.org just writes to public-inbox archives and    leaves mail delivery and subscription management up to someone else.

[...]
> The main upside of this approach is that it's evolutionary and not revolutionary and we can start implementing it right away, using it to augment and improve mailing lists instead of replacing them outright.

I do like these aspects, and the receive side aka git to mail client integration is already done,
so the one missing piece is a sendmail drop-in replacement acting as public git sent-mail folder.
I think it doesn't have to be on kernel.org, but could live anywhere e.g. developers could also
push to github or elsewhere with such tool, so "subscribing" to a mailing list for sending would
need kernel.org infra that adds the repo to a list of repos to pull from, extracts <commit hash>:m
from that developers repo from the point where it was last read up to the git HEAD (e.g. rejecting
any forced pushes, and doing sanity checks on m), and m would then be committed conflict-free to
the official public-inbox repositories of the lists in Cc in m, and potentially sent from kernel.org
via MTA bridge to old-style mail receivers. Nice thing is that this would allow for transparent
testing/roll-out to today's development workflow. It might be one component/(sub-)tool of the bigger
picture to have email slowly fade out (and new/non-mail based tools could be built around it, too).

Thanks,
Daniel