ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hurley <jhur...@hortonworks.com>
Subject Re: [DISCUSS] Future code review and commit process
Date Thu, 04 Jan 2018 15:51:05 GMT
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 <vivekratnavel@apache.org<mailto:vivekratnavel@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message