netdev - Keep bpf-next always open

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Sep 2020 14:19:56 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller" <davem@...emloft.net>,
        Kernel Team <Kernel-team@...com>
Subject: Keep bpf-next always open

BPF developers,

The merge window is 1.5 weeks away or 2.5 weeks if rc8 happens. In the past we
observed a rush of patches to get in before bpf-next closes for the duration of
the merge window. Then there is a flood of patches right after bpf-next
reopens. Both periods create unnecessary tension for developers and maintainers.
In order to mitigate these issues we're planning to keep bpf-next open
during upcoming merge window and if this experiment works out we will keep
doing it in the future. The problem that bpf-next cannot be fully open, since
during the merge window lots of trees get pulled by Linus with inevitable bugs
and conflicts. The merge window is the time to fix bugs that got exposed
because of merges and because more people test torvalds/linux.git than
bpf/bpf-next.git.

Hence starting roughly one week before the merge window few risky patches will
be applied to the 'next' branch in the bpf-next tree instead of
bpf-next/master. Then during the two weeks of the merge window the patches will
be reviewed as normal and will be applied to the 'next' branch as well. After
Linus cuts -rc1 and net-next reopens, we will fast forward bpf-next tree to
net-next tree and will try to merge the 'next' branch that accumulated the
patches over these three weeks. After fast-forward the bpf-next tree might look
very different vs its state before the merge window and there is a chance that
some of the patches in the 'next' branch will not apply. We will try to resolve
the conflicts as much as we can and apply them all. Essentially bpf-next/next
is a strong promise that the patches will land into bpf-next. This scheme will
allow developers to work on new features and post them for review and landing
regardless of the merge window or not. Having said that the bug fixing is
always a priority.

We've considered creating a bpf-next-next.git tree for this purpose, but decided
that bpf-next/next branch will be easier for everyone.

Thoughts and comments?