Re: Keep bpf-next always open

On Sep 23, 2020, at 3:28 PM, Alexei Starovoitov [off-list ref] wrote:

On Wed, Sep 23, 2020 at 10:23:51PM +0000, Song Liu wrote:

quoted

quoted

On Sep 23, 2020, at 3:14 PM, Alexei Starovoitov [off-list ref] wrote:

On Wed, Sep 23, 2020 at 02:48:24PM -0700, Andrii Nakryiko wrote:

quoted

On Wed, Sep 23, 2020 at 2:20 PM Alexei Starovoitov
[off-list ref] wrote:

quoted

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

Riskiness would be up to maintainers to determine or should we mark
patches with a different tag (bpf-next-next?) explicitly?

"Risky" in a sense of needing a revert. The bpf tree and two plus -rc1 to -rc7
weeks should be enough to address any issues except the most fundamental ones.
Something like the recent bpf_tail_call support in subprograms I would consider
for the "next" branch if it was posted a day before the merge window.
In practice, I suspect, such cases will be rare.

I think bpf-next-next tag should not be used. All features are for [bpf-next].
Fixes are for [bpf]. The bpf-next/next is a temporary parking place for patches
while the merge window is ongoing.

I wonder whether we can move/rename the branch around so that the developers can 
always base their work on bpf-next/master. Something like:

Long before merge window for 5.15:	
We only have bpf-next/master

1 week before merge window for 5.15:	
Clone bpf-next/master as bpf-next/for-5.15

From -1 week to the end of merge window
Risky features only goes to bpf-next/master, bug fix goes in both master and for-5.15

After merge window:
Fast forward bpf-next/master based on net-next. Deprecate for-5.15.

Would this work? 

It will create headaches for linux-next that merges bpf-next/master.
All linux-next trees should not add patches to those trees that are not going
into the merge window.

I see. Keeping bpf-next/master for linux-next/master does make sense. 

How about we keep bpf-next/next always open, or maybe rename it as bpf-next/dev?
Developers could always base their work on bpf-next/dev. When the maintainer 
applies the patch, he can decide whether to apply it to both master and dev, or
just dev. 

Thanks,
Song