On Sun, 7 Jul 2024 10:16:11 -0600 David Ahern <dsahern@xxxxxxxxxx> wrote: > On 7/6/24 1:56 PM, Stephen Hemminger wrote: > > The original point was to have kernel -next and iproute2 -next branches > > and have support arrive at same time on both sides. The problem is when > > developers get behind, and the iproute2 patches arrive after the kernel cycle > > and then would end up get delayed another 3 to 4 months. > > Then the userspace patches should be sent when the kernel patches are > merged. Period. no excuses. Any delay is on the developer. I would suggest that the netdev maintainers not accept any new feature to net-next (that uses iproute2) until/unless the iproute2 update patch has been posted. This prevents this problem, and the problem of getting userspace API wrong. > > > > > Example: > > If mst had been submitted during 6.9 -next open window, then > > it would have arrived in iproute2 when -next was merged in May 2024 and > > would get released concurrently with 6.10 (July 2024). > > When MST was submitted later, if it goes through -next, then it would > > get merged to main in August 2024 and released concurrently with 6.11 > > in October. By merging to main, it will be in July. > > Same exact problem with netkit and I told Daniel no. We have a > development policy for new features; it must apply across the board to > all of them. > > > > > I understand your concern, and probably better not to have done it. > > You applied patches for a new feature just a week or two before release. > It is just wrong. It would be best to either back up the branch or > revert them. Will backup the branch since these are the the last patches merged.
