+1 to the proposal. I agree on both points, and I think this is exactly the direction we should take.
On Fri, Aug 21, 2026 at 10:18 AM Jinbao Chen <[email protected]> wrote: > Hi Team, > > I hope you are all doing well. > > Currently, I am backporting a large volume of commits from the main branch > to REL_2_STABLE. > Although this task is nearing completion, the process along the way has > clearly been quite confusing. > > We need to clarify two key questions here: > > 1. Which commits should be backported? > 2. Who should be responsible for the backporting work? > > > First of all, I believe that if a commit is a bug fix, and that same bug > also exists in the stable version, then the commit should be submitted to > the stable branch. If it is a feature, we should not backport it unless > there is a definitive reason to do so. > > Furthermore, the backporting work should be done by the original author of > the commit. This time, a single person had to backport so many commits all > at once. It is very difficult for me to deeply understand the context and > purpose of every single commit, and it is impossible to carefully review > every line of code. This has brought huge challenges to the job, and it > also makes it very hard for me to determine whether a commit should be > backported or not > Bug fixes should be handled by the original author, at commit time. The author is the only person who really knows what the problem was, why the fix is correct, and whether the same bug exists on the stable branch. Asking one person to backport a large batch afterwards is not sustainable — it is unreasonable to expect them to reconstruct the context of every commit, and the review quality inevitably suffers. This is also how the PostgreSQL community works: a committer pushes the fix to master and to every affected supported branch in the same pass, not months later. Concrete proposal: tag the PR. To make this actionable rather than a convention people forget, I suggest we mark it on the PR itself. When a PR is opened (or during review), the author/reviewer adds a label such as 2X_STABLE to indicate "this must also land on the 2X_STABLE branch." Benefits: On features, I would be slightly more permissive than "default no". I agree features should not be backported blindly. But my main concern is release cadence: if a feature can only ship on main, users on the stable branch may wait a very long time for it. So I would propose the criterion be compatibility rather than "feature vs. fix": - If a feature does not introduce data or metadata (catalog / on-disk format) compatibility issues, and the author judges it low-risk for stability, it can go to 2X_STABLE. - If it touches data or catalog compatibility — or otherwise risks breaking upgrade/downgrade paths — it stays on main only. - The decision is made while the context is fresh, by the people who have it. - It becomes visible in review — a reviewer can push back with "this is a bug fix that also affects 2.x, please tag it." - We get a queryable list of what is pending backport, instead of diffing branches after the fact. - If we later support more stable branches, the same mechanism extends naturally (one label per branch). > > Above are my thoughts on this. Please let me know your thoughts or feedback > on this proposal. > Best regards, Max Yang
