Re: [PATCH v3 iproute2 0/4] Multiple Spanning Tree (MST) Support

[Stephen Hemminger <stephen@networkplumber.org>]

On Sat, 6 Jul 2024 09:26:46 -0600
David Ahern <dsahern@kernel.org> wrote:

> On 7/5/24 9:49 PM, Stephen Hemminger wrote:
> > On Fri, 5 Jul 2024 18:53:47 -0600
> > David Ahern <dsahern@kernel.org> wrote:
> >   
> >> On 7/5/24 11:31 AM, patchwork-bot+netdevbpf@kernel.org wrote:  
> >>> Hello:
> >>>
> >>> This series was applied to iproute2/iproute2.git (main)
> >>> by Stephen Hemminger <stephen@networkplumber.org>:
> >>>     
> >>
> >> Why was this merged to the main repro? As a new feature to iproute2 this
> >> should be committed to next and only put in main on the next dev cycle.  
> > 
> > Because the kernel support was already added, I prefer to not force waiting
> > for code that is non-intrusive and kernel support is already present.  
> 
> I have told multiple people - with you in CC - that is not how iproute2
> branching works. People need to send userspace patches for iproute2 in
> the same dev cycle as the kernel patches. You are now selectively
> undermining that process. What is the point of -next branch then?
 
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.

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.

I understand your concern, and probably better not to have done it.
The problem with accepting things early is the review process gets
truncated, and new features often have lots of feedback.