This model is quite different from the model which many of us have been using years. As such, I think we need to define a bit more structure so that we keep the project tidy and under control. A few points:
* Since this new flow model requires a branch for a commit, we should enforce a naming strategy. These short-lived feature branches for commits must be easy to find and remove. We should also make the community aware that once you have had your pull request merged, you should get rid of your branch. As for branch naming conventions, I haven't thought through it very much, but perhaps simply the name of the associated JIRA, such as AMBARI-12345. * We should also take this opportunity to go through any of our existing branches and clean out the ones which are very stale and not related to a prior release or existing feature under development. We have a branch named "trunkj" ... * Using longer-lived feature branches should remain similar to today and should work nicely with this model. When merging them incrementally, we can just keep them open after the pull request is merged. * I do not think that adding a [COMPONENT] tag is useful. Many commits span ambari-server and ambari-agent, and a good number also span ambari-web and ambari-server. I also think that we should have the title of the JIra match the commit exactly as we do today. On Jan 3, 2018, at 6:55 PM, Vivek Ratnavel <vivekratna...@apache.org<mailto:vivekratna...@apache.org>> wrote: Hi all, As we are linking our github accounts with gitbox to gain write access to github repository, I wanted to start a discussion on the future code review and commit process. After taking a look at other Apache projects including Apache Spark, I suggest we adapt the following flow: - A JIRA is created with all the required details at https://issues.apache.org/ - Create a new branch from local fork and push commits to that branch - Run all the tests and update or add new tests if required - Open a pull request against trunk or any other branch. I suggest using PR title format similar to what Apache Spark is using. 1. The pull request title should be of the form [AMBARI-xxxx][COMPONENT] Title, where AMBARI-xxxx is the relevant JIRA number, COMPONENT is one of the ambari components such as ambari-server, ambari-web, etc. and Title may be the JIRA’s title or a more specific title describing the PR itself. 2. If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to Github to facilitate review, then add [WIP] after the component. Following such a format to create pull requests will help us create a portal such as https://spark-prs.appspot.com/ in the future to keep track of open pull requests. Thanks to github's rich set of APIs. - Wait for a +1 or approval of PR from any committer. If there is a need for update, keep pushing commits to the same branch and notify the reviewer of the update. - If a PR has +1 from a committer, any committer can then go ahead and merge the PR and mark the JIRA as resolved Please let me know what you think about this flow. Your feedback is appreciated. Thanks, Vivek Ratnavel
