On Thu, Oct 23, 2025 at 10:37 PM <[email protected]> wrote: > 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. > This path is not well established. Past discussions around backporting have raised concerns about 'stability' of backporting changes which is fair but it leaves contributors who would like to backport patches without a choice. Isolating backports in a separate branch would allow us to mitigate those kinds of concern and establish a more liberal criteria to accept backported patches. We, as a project, currently lack concrete guidelines on what is and isn't acceptable to backport. There isn't an objective criteria establishing the level of risk associated with a proposed backport. It's mostly vibes based as most other things. 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 > Committers are not required to backport their features to these branches so I don't see this as 'mandatory' for all committers. Please elaborate if there are aspects of maintenance that I've missed. > to past feedback from multiple contributors highlighting the degree of > that burden or the high cost of undoing such a pilot. > Let's address the burden of undoing the cost of this pilot concretely. The cost as follows - 1. Stop maintaining the backports branch. 2. Stop producing any artifacts from backports branch. 3. Deprecating the released artifacts. 4. Retire CI. Is there any other cost related to retiring this pilot that you think I haven't accounted for? It also seems to suggest that there is consensus, and I don’t see that on > this thread or the other one. > The discussion is continuing because there is no consensus. Could you elaborate on what makes you say that there is suggestion of a consensus? 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. > Synchronous calls are not intended to exclude anybody. It will simply speed up the process of building consensus among those who are interested in joining such a call. The discussion has to ultimately land back on the dev list. Dinesh
