[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQKn=CxcOpjSWLsD+VC5rviC6sMfrhw5jrPCU60Bcx5Ssw@mail.gmail.com>
Date: Mon, 12 Oct 2020 13:15:16 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jakub Kicinski <kuba@...nel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Daniel Borkmann <daniel@...earbox.net>, bpf <bpf@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: merge window is open. bpf-next is still open.
On Mon, Oct 12, 2020 at 11:00 AM Jakub Kicinski <kuba@...nel.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.
Powered by blists - more mailing lists