sijie commented on issue #2526: [dev] provide a python merge script for merging pull requests URL: https://github.com/apache/incubator-pulsar/pull/2526#issuecomment-419144820 > In short, I think the root cause of the mess is not lack of tools but lack of clear policies. agreed. that's what I stated in the mail thread. what I need is a clear policy. the tool here is adding enforcement. > Where's the rule book? > Do we have a maintenance policy? > What commits have to be cherry-picked? To which branches? Until when? By Who? I have started the mail thread for almost a month, but really almost no one in the community is interested in discussing the rules. > I understand the motivation, however, I think we should discuss rules and policies, and should build a consensus first. Otherwise who can review and maintain the script correctly? I have started the discussion in the mail thread. This PR is just to demonstrate a proposal to follow what other project is doing spark, bookkeeper, kafka and many other ASF projects. If the community likes this approach, we can adopt it. If the community doesn't like the approach, it is okay since it is just a proposal, if there is other good approaches, please raise it up in the mail thread. > I'm fine with automating boring steps and preventing mistakes by using scripts, but it's questionable to me that we need complicated rules that we cannot manually apply correctly. First, Labeling the issues and marking milestone. It is the easiest part. If everyone can follow the rules, that is totally fine. However people are just lazy and steps are usually missed. Second, manage the commit message. when you click 'squash and merge' button, if you don't pay attention to copying the description in the PR to the merge text box, you will end up with a commit without description or with a mixed of random commits Last, manage the cherry-picks. that is the difficult part. currently we are using milestone for tracking the releases, however a PR can be linked to only one milestone. so if there is no accurate view on how a pull request lands at the git repo. for a release manager, 1) he has to either manually cherry-pick to branches and left a comment in the original pull request, or 2) he has to manually create a new PR for it, which I think it is a load to the release manager. For 1), those individual cherry-picks are not interconnected, when you look into a git log in the branch, you will never know if the change is a cherry-pick or a brand new commit. There is almost no way for people to traverse back the original change. For 2), it has to going to another review cycle and the problem listed above during merging will occur. I don't meant to introduce any overhead to the merging and releasing process. However I do think for Pulsar to become a success project, it has to do something on this management. At the end, to really know the pain points, I would suggest every committer in the community should do at least one bugfix release.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
