Versions Compared

Old Version 8

changes.mady.by.user guozhang Wang

Saved on

compared with

New Version 9

changes.mady.by.user Ismael Juma Juma

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Applied Jun's feedback regarding JIRA status and assignment.

...

  1. Find the existing Kafka JIRA ticket that the change pertains to.

    1. Do not create a new JIRA ticket if creating a change to address an existing issue ticket in JIRA; add to the existing discussion and work instead

    2. Look for existing pull requests that are linked from the JIRA ticket, to understand if someone is already working on the JIRAit

  2. If the change is new, then it usually needs a new JIRA ticket. However, trivial changes, where "what should change" is virtually the same as "how it should change" do not require a JIRA ticket. Example: "Fix typos in Foo scaladoc"

  3. If required, create a new JIRA ticket:

    1. Provide a descriptive Title. "Update web UI" or "Problem in scheduler" is not sufficient. "Kafka support fails to handle empty queue during shutdown" is good.

    2. Write a detailed Description. For bug reports, this should ideally include a short reproduction of the problem. For new features, it may include a design document (or a Kafka Improvement Proposal if it's a major change).

    3. Set required fields: Type, Priority, Fix Versions and optionally Labels.

    4. Do not include a patch file; pull requests are used to propose the actual change.

  4. To avoid conflicts, assign the JIRA ticket to yourself if you plan to work on it. Leave it unassigned otherwise.

  5. If the change is a large change, consider inviting discussion on the issue at dev@kafka.apache.org first before proceeding to implement the change.

...

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

    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. The related JIRA, if any, will be marked as "In Progress" and your pull request will automatically be linked to it.

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

The following steps are planned, but not yet configured.

...

  • Other reviewers, including committers, may comment on the changes and suggest modifications. Changes can be added by simply pushing more commits to the same branch.

  • Lively, polite, rapid technical debate is encouraged from everyone in the community. The outcome may be a rejection of the entire change.

  • Reviewers can indicate that a change looks suitable for merging with a comment such as: "I think this patch looks good". Kafka uses the LGTM convention for indicating the strongest level of technical sign-off on a patch: simply comment with the word "LGTM". It specifically means: "I've looked at this thoroughly and take as much ownership as if I wrote the patch myself". If you comment LGTM you will be expected to help with bugs or follow-up issues on the patch. Consistent, judicious use of LGTMs is a great way to gain credibility as a reviewer with the broader community.

  • The JIRA ticket status will changed from "Patch Available" to "In Progress" if the pull request needs more work.

  • Sometimes, other changes will be merged which conflict with your pull request's changes. The PR can't be merged until the conflict is resolved. This can be resolved with "git fetch origin" followed by "git rebase origin/trunk" and resolving the conflicts by hand, then pushing the result to your branch.

  • Try to be responsive to the discussion rather than let days pass between replies

...