BPF Archive on lore.kernel.org
 help / color / Atom feed
* merge window is open. bpf-next is still open.
@ 2020-10-12  0:59 Alexei Starovoitov
  2020-10-12 18:00 ` Jakub Kicinski
  0 siblings, 1 reply; 7+ messages in thread
From: Alexei Starovoitov @ 2020-10-12  0:59 UTC (permalink / raw)
  To: Daniel Borkmann, bpf, Network Development, Kernel Team, David S. Miller

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!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: merge window is open. bpf-next is still open.
  2020-10-12  0:59 merge window is open. bpf-next is still open Alexei Starovoitov
@ 2020-10-12 18:00 ` Jakub Kicinski
  2020-10-12 20:15   ` Alexei Starovoitov
  0 siblings, 1 reply; 7+ messages in thread
From: Jakub Kicinski @ 2020-10-12 18:00 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Daniel Borkmann, bpf, Network Development, Kernel Team, David S. Miller

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?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: merge window is open. bpf-next is still open.
  2020-10-12 18:00 ` Jakub Kicinski
@ 2020-10-12 20:15   ` Alexei Starovoitov
  2020-10-12 20:50     ` Stephen Rothwell
  0 siblings, 1 reply; 7+ messages in thread
From: Alexei Starovoitov @ 2020-10-12 20:15 UTC (permalink / raw)
  To: Jakub Kicinski, Stephen Rothwell
  Cc: Daniel Borkmann, bpf, Network Development, Kernel Team, David S. Miller

On Mon, Oct 12, 2020 at 11:00 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> 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.

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: merge window is open. bpf-next is still open.
  2020-10-12 20:15   ` Alexei Starovoitov
@ 2020-10-12 20:50     ` Stephen Rothwell
  2020-10-12 21:03       ` Alexei Starovoitov
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2020-10-12 20:50 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Jakub Kicinski, Daniel Borkmann, bpf, Network Development,
	Kernel Team, David S. Miller


[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

Hi Alexei,

On Mon, 12 Oct 2020 13:15:16 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: merge window is open. bpf-next is still open.
  2020-10-12 20:50     ` Stephen Rothwell
@ 2020-10-12 21:03       ` Alexei Starovoitov
  2020-10-12 22:42         ` Daniel Borkmann
  2020-10-13  1:58         ` Stephen Rothwell
  0 siblings, 2 replies; 7+ messages in thread
From: Alexei Starovoitov @ 2020-10-12 21:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jakub Kicinski, Daniel Borkmann, bpf, Network Development,
	Kernel Team, David S. Miller

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 <alexei.starovoitov@gmail.com> 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?)

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: merge window is open. bpf-next is still open.
  2020-10-12 21:03       ` Alexei Starovoitov
@ 2020-10-12 22:42         ` Daniel Borkmann
  2020-10-13  1:58         ` Stephen Rothwell
  1 sibling, 0 replies; 7+ messages in thread
From: Daniel Borkmann @ 2020-10-12 22:42 UTC (permalink / raw)
  To: Alexei Starovoitov, Stephen Rothwell
  Cc: Jakub Kicinski, bpf, Network Development, Kernel Team, David S. Miller

On 10/12/20 11:03 PM, Alexei Starovoitov wrote:
> On Tue, Oct 13, 2020 at 07:50:16AM +1100, Stephen Rothwell wrote:
[...]
>> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: merge window is open. bpf-next is still open.
  2020-10-12 21:03       ` Alexei Starovoitov
  2020-10-12 22:42         ` Daniel Borkmann
@ 2020-10-13  1:58         ` Stephen Rothwell
  1 sibling, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2020-10-13  1:58 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Jakub Kicinski, Daniel Borkmann, bpf, Network Development,
	Kernel Team, David S. Miller


[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

Hi Alexei,

On Mon, 12 Oct 2020 14:03:07 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-12  0:59 merge window is open. bpf-next is still open Alexei Starovoitov
2020-10-12 18:00 ` Jakub Kicinski
2020-10-12 20:15   ` Alexei Starovoitov
2020-10-12 20:50     ` Stephen Rothwell
2020-10-12 21:03       ` Alexei Starovoitov
2020-10-12 22:42         ` Daniel Borkmann
2020-10-13  1:58         ` Stephen Rothwell

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git