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:   Fri, 29 Dec 2017 20:00:28 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Leon Romanovsky <leon@...nel.org>, netdev@...r.kernel.org,
        dsa@...ulusnetworks.com
Subject: Re: iproute2 net-next

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ