merge window is open. bpf-next is still open.

Hi BPF developers,

The merge window has just opened.
Which would typically mean that bpf-next is closing,
but things are going to be a little bit different this time.
We're stopping to accept new features into bpf-next/master.
The few pending patches might get applied and imminent pull-req into
net-next will be sent.
After that bpf-next/master will be frozen for the duration of the merge window,
but bpf-next/next branch will be open for the new features.

So please continue the BPF development and keep sending your patches.
They will be reviewed as usual.
After the merge window everything that is accumulated in bpf-next/next
will be applied to bpf-next/master.
Due to merge/rebase sha-s in bpf-next/next will likely be unstable.

Please focus on fixing bugs that may get exposed during the merge window.
The bpf tree is always open for bug fixes.

Thanks!

On Sun, 11 Oct 2020 17:59:16 -0700 Alexei Starovoitov wrote:

Hi BPF developers,

The merge window has just opened.
Which would typically mean that bpf-next is closing,
but things are going to be a little bit different this time.
We're stopping to accept new features into bpf-next/master.
The few pending patches might get applied and imminent pull-req into
net-next will be sent.
After that bpf-next/master will be frozen for the duration of the merge window,
but bpf-next/next branch will be open for the new features.

So please continue the BPF development and keep sending your patches.
They will be reviewed as usual.
After the merge window everything that is accumulated in bpf-next/next
will be applied to bpf-next/master.
Due to merge/rebase sha-s in bpf-next/next will likely be unstable.

Please focus on fixing bugs that may get exposed during the merge window.
The bpf tree is always open for bug fixes.

FWIW for CIs switching between bpf-next/next and bpf-next/master could
be somewhat fragile. Since bpf-next/master is frozen during the merge
window, why not apply the patches there?

On Mon, Oct 12, 2020 at 11:00 AM Jakub Kicinski [off-list ref] wrote:

On Sun, 11 Oct 2020 17:59:16 -0700 Alexei Starovoitov wrote:

quoted

Hi BPF developers,

The merge window has just opened.
Which would typically mean that bpf-next is closing,
but things are going to be a little bit different this time.
We're stopping to accept new features into bpf-next/master.
The few pending patches might get applied and imminent pull-req into
net-next will be sent.
After that bpf-next/master will be frozen for the duration of the merge window,
but bpf-next/next branch will be open for the new features.

So please continue the BPF development and keep sending your patches.
They will be reviewed as usual.
After the merge window everything that is accumulated in bpf-next/next
will be applied to bpf-next/master.
Due to merge/rebase sha-s in bpf-next/next will likely be unstable.

Please focus on fixing bugs that may get exposed during the merge window.
The bpf tree is always open for bug fixes.

FWIW for CIs switching between bpf-next/next and bpf-next/master could
be somewhat fragile.

CIs can adjust. That's not a big deal, but having two branches definitely
adds a point of confusion to people.
Song proposed earlier to use bpf-next/dev and push patches into /master and
into /dev branches always, so folks/CI can always use bpf-next/dev.
Unfortunately sha-s will be different, so it's not workable.

Since bpf-next/master is frozen during the merge
window, why not apply the patches there?

You mean keep pushing into bpf-next/master ?
The only reason is linux-next.
But coming to think about it again, let's fix linux-next process instead.

Stephen,
could you switch linux-next to take from bpf.git during the merge window
and then go back to bpf-next.git after the merge window?
That will help everyone. CIs wouldn't need to flip flop.
People will keep basing their features on bpf-next/master all the time, etc.
The only inconvenience is for linux-next. I think that's a reasonable trade-off.
In other words bpf-next/master will always be open for new features.
After the merge window bpf-next/master will get rebased to rc1.

Hi Alexei,

On Mon, 12 Oct 2020 13:15:16 -0700 Alexei Starovoitov [off-list ref] wrote:

You mean keep pushing into bpf-next/master ?
The only reason is linux-next.
But coming to think about it again, let's fix linux-next process instead.

Stephen,
could you switch linux-next to take from bpf.git during the merge window
and then go back to bpf-next.git after the merge window?
That will help everyone. CIs wouldn't need to flip flop.
People will keep basing their features on bpf-next/master all the time, etc.
The only inconvenience is for linux-next. I think that's a reasonable trade-off.
In other words bpf-next/master will always be open for new features.
After the merge window bpf-next/master will get rebased to rc1.

I already fetch bpf.git#master all the time (that is supposed to be
fixes for the current release and gets merged into the net tree, right?)

How about this: you create a for-next branch in the bpf-next tree and I
fetch that instead of your master branch.  What you do is always work
in your master branch and whenever it is "ready", you just merge master
into for-next and that is what linux-next works with (net-next still
merges your master branch as now).  So the for-next branch consists
only of consecutive merges of your master branch.

During the merge window you do *not* merge master into for-next (and,
in fact, everything in for-next should have been merged into the
net-next tree anyway, right?) and then when -rc1 is released, you reset
for-next to -rc1 and start merging master into it again.

This way the commit SHA1s are stable and I don't have to remember to
switch branches/trees every merge window (which I would forget
sometimes for sure :-)).
-- 
Cheers,
Stephen Rothwell

On Tue, Oct 13, 2020 at 07:50:16AM +1100, Stephen Rothwell wrote:

Hi Alexei,

On Mon, 12 Oct 2020 13:15:16 -0700 Alexei Starovoitov [off-list ref] wrote:

quoted

You mean keep pushing into bpf-next/master ?
The only reason is linux-next.
But coming to think about it again, let's fix linux-next process instead.

Stephen,
could you switch linux-next to take from bpf.git during the merge window
and then go back to bpf-next.git after the merge window?
That will help everyone. CIs wouldn't need to flip flop.
People will keep basing their features on bpf-next/master all the time, etc.
The only inconvenience is for linux-next. I think that's a reasonable trade-off.
In other words bpf-next/master will always be open for new features.
After the merge window bpf-next/master will get rebased to rc1.

I already fetch bpf.git#master all the time (that is supposed to be
fixes for the current release and gets merged into the net tree, right?)

Correct. That part doesn't change.

How about this: you create a for-next branch in the bpf-next tree and I
fetch that instead of your master branch.  What you do is always work
in your master branch and whenever it is "ready", you just merge master
into for-next and that is what linux-next works with (net-next still
merges your master branch as now).  So the for-next branch consists
only of consecutive merges of your master branch.

During the merge window you do *not* merge master into for-next (and,
in fact, everything in for-next should have been merged into the
net-next tree anyway, right?) and then when -rc1 is released, you reset
for-next to -rc1 and start merging master into it again.

This way the commit SHA1s are stable and I don't have to remember to
switch branches/trees every merge window (which I would forget
sometimes for sure :-)).

That is a great idea! I think that should work well for everyone.
Let's do exactly that.
Just pushed bpf-next/for-next branch.

I'll send a patch to update Documentation/bpf/bpf_devel_QA.rst
with all these details later today.

On 10/12/20 11:03 PM, Alexei Starovoitov wrote:

On Tue, Oct 13, 2020 at 07:50:16AM +1100, Stephen Rothwell wrote:

[...]

quoted

How about this: you create a for-next branch in the bpf-next tree and I
fetch that instead of your master branch.  What you do is always work
in your master branch and whenever it is "ready", you just merge master
into for-next and that is what linux-next works with (net-next still
merges your master branch as now).  So the for-next branch consists
only of consecutive merges of your master branch.

During the merge window you do *not* merge master into for-next (and,
in fact, everything in for-next should have been merged into the
net-next tree anyway, right?) and then when -rc1 is released, you reset
for-next to -rc1 and start merging master into it again.

This way the commit SHA1s are stable and I don't have to remember to
switch branches/trees every merge window (which I would forget
sometimes for sure :-)).

That is a great idea! I think that should work well for everyone.
Let's do exactly that.
Just pushed bpf-next/for-next branch.

+1, I like it as it keeps things simple & straight forward for contributors
and for linux-next as well.

Thanks,
Daniel

Hi Alexei,

On Mon, 12 Oct 2020 14:03:07 -0700 Alexei Starovoitov [off-list ref] wrote:

That is a great idea! I think that should work well for everyone.
Let's do exactly that.
Just pushed bpf-next/for-next branch.

From now on I will only fetch the for-next branch.

Thanks.
-- 
Cheers,
Stephen Rothwell