netdev - Re: iproute2 net-next

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 09:58:23 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Leon Romanovsky <leon@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org, dsa@...ulusnetworks.com
Subject: Re: iproute2 net-next

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