Versions Compared

Old Version 12

changes.mady.by.user Ismael Juma Juma

Saved on

compared with

New Version 13

changes.mady.by.user Ismael Juma Juma

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Explain that [MINOR] and [HOTFIX] can be used as a PR prefix instead of the JIRA reference.

...

  1. Fork the Github repository at http://github.com/apache/kafka if you haven't already

  2. Clone your fork, create a new branch, push commits to the branch (review the Kafka Coding Guidelines, if you haven't already).

  3. Consider whether documentation or tests need to be added or updated as part of the change, and add them as needed.

  4. Run all tests as described in the project's README.

  5. Open a pull request against the trunk branch of apache/kafka. (Only in special cases would the PR be opened against other branches.)

    1. The PR title should be usually be of the form [KAFKA-xxxx] Title, where KAFKA-xxxx is the relevant JIRA id and Title may be the JIRA's title or a more specific title describing the PR itself. For trivial cases where a JIRA is not required (see JIRA section for more details) [MINOR] or [HOTFIX] can be used as the PR title prefix.

    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 JIRA id.

    3. Consider identifying committers or other contributors who have worked on the code being changed. Find the file(s) in Github and click "Blame" to see a line-by-line annotation of who changed the code last and check the Maintainers page. You can add @username in the PR description to ping them immediately.

    4. Please state that the contribution is your original work and that you license the work to the project under the project's open source license.

  6. A comment with information about the pull request will be added to the JIRA ticket.

  7. Change the status of the JIRA to "Patch Available" if it's ready for review.

  8. The Jenkins automatic pull request builder will test your changes

    1. If it is your first contribution, Jenkins will wait for confirmation before building your code and post "Can one of the admins verify this patch?"

    2. A committer can authorize testing with a comment like "ok to test"

    3. A committer can automatically allow future pull requests from a contributor to be tested with a comment like "Jenkins, add to whitelist"

  9. Once ready, the test results will be posted on the pull request, along with a link to the full results on Jenkins.

  10. Watch for the results, and investigate and fix failures promptly

    1. Fixes can simply be pushed to the same branch from which you opened your pull request

    2. Jenkins will automatically re-test when new commits are pushed

    3. If the tests failed for reasons unrelated to the change (e.g. Jenkins outage), then a committer can request a re-test with "Jenkins, retest this please". Ask if you need a test restarted.

...