On Mon, 15 Jan 2018 19:59:05 -0700, David Ahern wrote: > On 1/15/18 6:56 PM, Marcelo Ricardo Leitner wrote: > > On Fri, Dec 29, 2017 at 08:00:28PM -0800, Stephen Hemminger wrote: > >> On Fri, 29 Dec 2017 09:58:23 +0100 > >> Jiri Pirko <j...@resnulli.us> wrote: > >> > >>> Fri, Dec 29, 2017 at 12:46:31AM CET, dan...@iogearbox.net wrote: > >>>> On 12/26/2017 10:35 AM, Leon Romanovsky wrote: > >>>>> On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote: > >>>>>> On Tue, 26 Dec 2017 06:47:43 +0200 > >>>>>> Leon Romanovsky <l...@kernel.org> wrote: > >>>>>> > >>>>>>> On Mon, Dec 25, 2017 at 10:49:19AM -0800, Stephen Hemminger wrote: > >>>>>>>> David Ahern has agreed to take over managing the net-next branch of > >>>>>>>> iproute2. > >>>>>>>> The new location is: > >>>>>>>> > >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/dsahern/iproute2-next.git/ > >>>>>>>> > >>>>>>>> In the past, I have accepted new features into iproute2 master > >>>>>>>> branch, but > >>>>>>>> am changing the policy so that outside of the merge window (up until > >>>>>>>> -rc1) > >>>>>>>> new features will get put into net-next to get some more review and > >>>>>>>> testing > >>>>>>>> time. This means that things like the proposed batch streaming mode > >>>>>>>> will > >>>>>>>> go through net-next. > >>>>>>> > >>>>>>> Did you consider to create one shared repo for the iproute2 to allow > >>>>>>> multiple committers workflow? > >>>>>> > >>>>>> For now having separate trees is best, there is no need for multiple > >>>>>> committers the load is very light. > >>>>>> > >>>>>>> It will be much convenient for the users to have one place for > >>>>>>> master/stable/net-next branches, instead of actually following two > >>>>>>> different repositories. > >>>>>> > >>>>>> If you are doing network development, you already need to deal with > >>>>>> multiple repo's on the kernel side so there is no difference. > >>>>> > >>>>> I agree with you that one extra "git remote add .." is not so huge and > >>>>> all people who develop for the netdev will do it. My concern is about > >>>>> Documentation and newcomers, who will have a hard time to find a right > >>>>> tree. > >>>> > >>>> I guess it would certainly help to identify the official repo to rebase > >>>> against much quicker if it would be under a common group on korg e.g. > >>>> > >>>> * iproute2/iproute2.git - for current cycle > >>>> * iproute2/iproute2-next.git - for net-next bits > >>>> > >>>> and also be in line with other tooling (ethtool and others), even if > >>>> not as high volume, but it would make it unambiguous right away from > >>>> the other, private iproute2 repos on korg, imho. Just a thought. > >>> > >>> +1 > >>> > >>> I was about to suggest this. This is nice opportunity to do such change. > >>> > >>> > >>>> > >>>>>>> Example, of such shared repo: > >>>>>>> BPF: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/ > >>>>>>> Bluetooth: > >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/ > >>>>>>> RDMA: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/ > >>>>>>> > >>>>>> > >>>>>> Most of these are high volume or vendor silo'd which is not the case > >>>>>> here. > >>>> Cheers, > >>>> Daniel > >> > >> Good news > >> kup does support links so could make links from personal to iproute2 > >> directory > >> > >> Bad news > >> kup won't allow me to make iproute2 directory right now. Will have to wait > >> for > >> Konstantin > >> > > > > Hi, any news on this? Not sure if Konstantin is back already or not. > > Done a few days ago. The new canonical URLs for those repos are: > pub/scm/network/iproute2/iproute2 > pub/scm/network/iproute2/iproute2-next > > So clone URLs > git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git > https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git > and > git://git.kernel.org/pub/scm/network/iproute2/iproute2.git > https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
About the branches - what should we base our patches on for net-next? Most -next repos just use the master, but it seems that in case of iproute2-next.git the net-next branch is still active, and there is an inactive net-next branch in iproute2.git.. Is this transitional or will it stay this way?
