Hi Alexei, On Mon, 12 Oct 2020 13:15:16 -0700 Alexei Starovoitov <alexei.starovoi...@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
pgpzFneun1RPb.pgp
Description: OpenPGP digital signature
