> However, in async work, people should have more patience to read and write.
I mean, it would be better to have something like "TL; DR". Anyway, I'd like to apply this change since the next feature release (3.3.0). Thanks, Yunze On Tue, Mar 19, 2024 at 12:10 AM Lari Hotari <lhot...@apache.org> wrote: > > Thanks for the comments, Yunze. > > On 2024/03/18 05:48:39 Yunze Xu wrote: > > I'm afraid many people don't have patience to read all the contents. > > I agree. However, in async work, people should have more patience to read and > write. Synchronous meetings aren't a good solution either. The lack of > patience could be caused by lack of interest. There's not a large group of > people in our community that are interested in improving the maintenance > strategy and also committed to invest their time and effort in these > activities. I hope more people sign up to this type of efforts and show their > interest and commitment in improving Apache Pulsar. > > > 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 > > I didn't describe the details of how this is handle. It is different in > practice. > > > - For features, the target branch should be branch-3.x > > New features would continue to go to master (or "main" if we decide to rename > it). Bugs would be fixed in the branch where the feature containing the bug > was introduced if it is missing from the LTS branch. > > > 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. > > Yes. > > -Lari > > On 2024/03/18 05:48:39 Yunze Xu wrote: > > 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 > > > > > >
