I'm afraid many people don't have patience to read all the contents. Here is my summary in short (please correct me if I'm wrong): - For bug fixes, the target branch should be branch-3.0. Once the PR is merged into branch-3.0, checkout the branch-3.x and run `git merge branch-3.0` and resolve the conflicts - For features, the target branch should be branch-3.x
Since we introduced the LTS concept, I agree that we should make branch-3.0 as the default branch. Cherry-picking is a disaster when cherry-picks happen in the wrong order. Thanks, Yunze On Tue, Mar 5, 2024 at 8:38 PM Lari Hotari <lhot...@apache.org> wrote: > > To enhance our maintenance processes, I've created a guide for > configuring "git mergetool" to resolve merge conflicts: > > https://pulsar.apache.org/contribute/setup-mergetool/ > > For Apache Pulsar core developers, managing git merge conflict > resolution is a necessary task. To streamline this process, it's crucial > to set up tools that aid in visualizing and resolving these conflicts. > > I encourage you to follow the guide to set up a git mergetool. Your > feedback is valuable, and you're welcome to contribute improvements > directly to the website. You can do this by creating a PR by editing > https://github.com/apache/pulsar-site/edit/main/contribute/setup-mergetool.md > directly in your browser. > > -Lari > > On 2024/03/01 14:01:55 Lari Hotari wrote: > > Dear Pulsar Community, > > > > As we prepare for new releases in our maintenance branches, we have once > > again encountered issues with our cherry-picking process. Some of our > > maintenance branches are currently broken or were recently broken, > > containing compilation errors or failing tests. Many have encountered > > these issues, as we have seen new PRs come in to address the > > problems. The compilation problems are already being addressed by > > Heesung (release manager for 3.0.3) and myself. We aim to resolve these > > issues as soon as possible. Please join #dev channel on Apache Pulsar > > Slack to collaborate in real time to help with this and get updates. > > > > The cherry-picking process has always been problematic and lacks clear > > documentation in Apache Pulsar. This often leads to our maintenance > > branches breaking, especially as we approach release dates and begin > > cherry-picking fixes. This recurring issue has been the subject of > > multiple discussions over the years. The "feature freeze" in the release > > process does not mitigate the key problem with the cherry-picking > > approach. > > > > Furthermore, the cherry-picking process is mostly based on tribal > > knowledge and lacks clear documentation. I have previously expressed my > > concerns about this on the mailing list in this thread: > > https://lists.apache.org/thread/69mwjso51kzkrv5xgdmw04d9wngbg8br > > > > Many problems with cherry-picking arise because cherry-picks occur in > > the wrong order, or dependent changes are not picked. Some dependent > > changes shouldn't be picked since when we have made bug fixes in the > > master branch, it can already contain changes for new features that > > shouldn't be applied to maintenance branches. In those cases > > a backport of the fix is needed and the original developer of the > > PR might not be available to do this and there could be a significant > > delay for the release if delivering the backport takes time. > > > > When cherry-picking and backporting is delegated to other developers, > > in addition to delays, it can lead to coordination problems and commits > > being picked and applied in an order that results in even more merge > > conflicts. Thankfully, this isn't usually too painful, but it does > > happen once in a while. > > > > A few days ago, I began working on improving the documentation of the > > current process. I have added a section where I share some thoughts and > > a tool to prevent future problems. You can find the document here: > > https://pulsar.apache.org/contribute/release-process/#cherry-picking-changes-scheduled-for-the-release. > > However, this does not fully describe the current process and will only > > help to some extent. > > > > The added section should help prevent cherry-picking in the wrong order, > > but it still has many gaps. Many developers do not have proper merge > > conflict resolution tools configured. Without proper 3-way diff > > visualization and merge tools, it's very difficult to resolve many of > > the merge conflicts without making mistakes. This also requires a deep > > understanding of the module where the conflicts occur. > > > > After we have made the next set of maintenance releases, I plan to > > propose an alternative to the cherry-picking process that will address > > the main issues that the Apache Pulsar project has been struggling with > > every time we do releases. > > > > The alternative would be to designate the LTS branch as the default > > branch, make bug fixes primarily in the LTS branch, merge fixes to newer > > branches, and cherry-pick to possible older branches. This common > > approach in many projects leverages what Git does well: handling > > development across multiple branches. This solution ensures that our LTS > > branch is always immediately in a releasable state and the branch will > > also become the most stable version of Pulsar since bug fixes are > > continuously evaluated and integrated into the LTS branch with our CI > > where bug fix PRs are targeted to the LTS branch. > > Stability was the original goal of PIP-175 where the LTS concept was > > introduced to Pulsar. > > > > I hope that our community would be open to making changes to the > > maintenance strategy to help resolve the pain that we have to deal with > > each time we make releases. Sometimes, this "cherry-picking vs. merging > > branches" discussion becomes a "tabs vs. spaces" type of pointless > > discussion where personal preferences are emphasized. I hope that we can > > avoid that and admit the fact that releasing Apache Pulsar LTS with this > > cherry-picking process is a pain and we must fix it to make progress as > > a development community. > > > > -Lari > >
