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]
Message-ID: <1f0599ae-fa64-548d-e7e1-c87c8731550a@iogearbox.net>
Date:   Sat, 30 Dec 2017 21:24:40 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        Jiri Pirko <jiri@...nulli.us>
Cc:     Leon Romanovsky <leon@...nel.org>, netdev@...r.kernel.org,
        dsa@...ulusnetworks.com
Subject: Re: iproute2 net-next

On 12/30/2017 05:00 AM, 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

That's nice indeed!

> Bad news
> kup won't allow me to make iproute2 directory right now. Will have to wait for
> Konstantin

Right, he also did set up the shared dir for bpf which was straight forward
though, so would be pretty much the same one-time procedure for iproute2.

Thanks,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ