Date:   Mon, 15 Jan 2018 23:56:14 -0200
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Daniel Borkmann <daniel@...earbox.net>,
        Leon Romanovsky <leon@...nel.org>, netdev@...r.kernel.org,
        dsa@...ulusnetworks.com
Subject: Re: iproute2 net-next

On Fri, Dec 29, 2017 at 08:00:28PM -0800, Stephen Hemminger wrote:
> On Fri, 29 Dec 2017 09:58:23 +0100
> Jiri Pirko <jiri@...nulli.us> wrote:
> 
> > Fri, Dec 29, 2017 at 12:46:31AM CET, daniel@...earbox.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 <leon@...nel.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.

Thanks,
Marcelo

Powered by blists - more mailing lists