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. > > 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. > The problem with accepting things early is the review process gets > truncated, and new features often have lots of feedback. > I see no problem here; that is normal development work.
