There is a path forward for such backports to be contributed today, and it’s 
pretty well established.

One sends an email to the dev list and proposes intent to backport a change or 
feature to a branch that wouldn’t ordinarily be a target for the change. Absent 
concern, the backport proceeds. In the presence of disagreement, discussion and 
a vote may follow to determine the appropriate path. All contributors are 
welcome to exercise this process, and I think we should do this more often. I’m 
surprised throughout this discussion that no one has done so and would 
encourage them to if they have a patch they’d like to backport.

I’m concerned that this message seems to try to soften the proposal to 
establish new branches that are mandatory for all committers to maintain by 
framing it as a “pilot," but does not respond to past feedback from multiple 
contributors highlighting the degree of that burden or the high cost of undoing 
such a pilot. It also seems to suggest that there is consensus, and I don’t see 
that on this thread or the other one.

A synchronous call at a particular time will exclude many from participation 
either due to time zones or scheduling conflicts. This list seems like the best 
place to have that discussion.

– Scott

> On Oct 23, 2025, at 10:09 PM, Dinesh Joshi <[email protected]> wrote:
> 
> On Thu, Oct 23, 2025 at 5:49 PM Jon Haddad <[email protected] 
> <mailto:[email protected]>> wrote:
>> 
>> I’m opposed to teams solving their technical debt issues by pushing more 
>> responsibility onto the project.  
> 
> There are no teams here. There is just the project and contributors. Official 
> backports are not a new or novel concept in open source projects. Whatever is 
> being discussed here needs to be sustainably supported by the project in the 
> longterm.
> 
> We have volunteers who are willing to participate in backporting some 
> features. The project needs to create a path forward for them to contribute. 
> The concerns around sustainability, testing, support are valid and there are 
> suggestions to mitigate those concerns. Assuming all goes well with the 
> pilot, it will help grow the project. If it doesn't go well, it's not a big 
> deal. This is not an irreversible decision – hence the suggestion for a 
> limited time pilot.
> 
> Given that there has been a lot of interest in this conversation, I suggest 
> we organize a call to discuss this. It might help with questions that 
> everybody has. We can then bring it back to the dev list.
> 
> Thoughts?
> 
> Dinesh

Reply via email to