maskit commented on issue #2526: [dev] provide a python merge script for merging pull requests URL: https://github.com/apache/incubator-pulsar/pull/2526#issuecomment-419464632 > agreed. that's what I stated in the mail thread. what I need is a clear policy. the tool here is adding enforcement. > 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 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 sorry for not responding on the mail thread. However, as you commented, a clear policy is what we need. If we just borrowed scripts from another project, the policy would keep unclear to people who are not participating the project. I'd like to see the policy that is coded into the script. We can enforce the policy later by using the script. > 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. I think we need to get used to doing it, and committers should be responsible for checking these things. ATS community is doing this pretty well without tools. A clear policy would be a help. > 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 The same as above. Committers should take care of this. I don't think automating it always ends up with the best result. > 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. I understand the difficulty. ATS community is facing the same issue. To deal with it, they also use Project for backporting request management. It's still too early to say it's working well, but I think it worth to try. > 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. In ATS community, they uses `-x` when they cherry-pick commits. This option appends the original commit hash to the commit log. > For 2), it has to going to another review cycle and the problem listed above during merging will occur. In ATS community, they make PRs for backporting only if the commit cannot be cherry-picked cleanly due to conflicts. And RM basically doesn't make PRs by himself but ask the original author to do so because RM isn't familiar with the change/module in some cases. RM just check that PRs are in policy and merge them. > 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. I understand and agree. > At the end, to really know the pain points, I would suggest every committer in the community should do at least one bugfix release. I don't disagree but that would take time. Since you are trying to enforce a policy, I guess you already have good examples for explaining the pain and how the policy solve it, right? Why don't you share those examples?
---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
