On Thu, Aug 15, 2024 at 12:15 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > > > 2. Non-networking bpf commits land in bpf-next/master branch. > > It will form bpf-next PR during the merge window. > > > > 3. Networking related commits (like XDP) land in bpf-next/net branch. > > They will be PR-ed to net-next and ffwded from net-next > > as we do today. All these patches will get to mainline > > via net-next PR. > > So from a submitter PoV, someone submitting an XDP-related patch (say), > should base this off of bpf-next/net, and tag it as bpf-next in the > subject? Or should it also be tagged as bpf-next/net? This part we're still figuring out. There are few considerations... it's certainly easier for bpf CI when the patch set is tagged with [PATCH bpf-next/net] then CI won't try to find the branch, but it will take a long time to teach all contributors to tag things differently, so CI would need to get smart anyway and would need to apply to /master, run tests, apply to /net, run tests too. Currently when there is no tag CI attempts to apply to bpf.git, if it fails, it tries to apply to bpf-next/master and only then reports back "merge conflict". It will do this for bpf, bpf-next/master, bpf-next/net now. Sometimes devs think that the patch is a fix, so they tag it with [PATCH bpf], but it might not be, and after review we apply it to bpf-next instead. So tree/branch to base patches off and tag don't matter that much. So I hope, in practice, we won't need to teach all developers about new tag and about new branch. We certainly won't be asking to resubmit if patches are not tagged one way or the other, but if you want to help CI and tell maintainers your preferences then certainly start using [PATCH bpf-next] and [PATCH bpf-next/net] when necessary. Or don't :) and instead help us make CI smarter :)
