Resending since the list apparently never got the emails I sent last Friday... From: Dave Thaler Sent: Friday, September 9, 2022 9:15 PM To: bpf@xxxxxxxxxxxxxxx Subject: ebpf-docs: cross-platform collaboration brainstorming Last month we had a bpf standardization meeting during the bpf office hours slot. We can discuss again at LPC, but I wanted to put a few things out on the list for discussion beforehand, to seed discussion. This email focuses on the cross-platform (not just Linux) collaboration aspect. I'd like to make it easy for people from multiple ecosystems (Linux, Windows, etc.) to be able to collaborate effectively and efficiently. As Mykola's notes from the meeting summarized: > Standardization artifacts will be upstreamed in the Linux kernel tree. > Communication will be done over the email using BPF mailing lists. > Now, the BPF community will look for volunteers to drive the effort. And we also said the eBPF Foundation should publish a snapshot in PDF format. I wanted now to get back to my latest thoughts on how to submit/review patches, to start some more brainstorming (but keeping in mind that this list is a primarily Linux-centric audience, rather than the full audience though we'd really like this list to not be Linux-only). I've heard from Linux kernel folks that creating a github account is too high a burden, whereas using the bpf list for patch review is the norm in ebpf today. And I've heard from folks that use github for ebpf projects that "git send-email" is a burden (or even apparently incompatible) for people using Exchange two-factor-auth which seems to preclude SMTP as required by git send-email. I'm hypothesizing some future solution that would somehow accommodate BOTH ways of working, while retaining the main agreements from in the meeting notes. We already have github mirrors of libbpf and bpftool, so having a mirror of any ebpf-docs is straightforward, which make consumption easy but by itself doesn't help contribution. We also already have https://github.com/iovisor/bpf-docs in github which is not authoritative or a mirror, but rather a logically separate effort it seems. So in a hypothetically ideal world, a patch would show up both on the bpf mailing list and as a github PR, where doing either one would result in the other happening automatically. I expect that may be impractical at least in the short term, though I'd love to hear of anyone knows of tools that could be used to do parts of that. A possible intermediate workaround might be if (say) 2 folks involved in the standardization effort manually did the mirroring, and then over time that gets automated. Other ideas? My goal would be to unify the discussion rather than splitting discussion into two separate places (as arguably is already the case with iovisor/bpf-docs vs kernel.org docs). Dave
