netdev - Re: merge window is open. bpf-next is still 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-prev] [thread-next>] [day] [month] [year] [list]

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.