Page History

...

• Is it clear that code must change? Proposing a JIRA and pull request is appropriate only when a clear problem or change has been identified. If simply having trouble using BookKeeper, use the mailing list first, rather than considering filing a JIRA or proposing a change. When in doubt, email user@bookkeeper.apache.org first about the possible change.
• Search the user@bookkeeper.apache.org and dev@bookkeeper.apache.org mailing list archives for related discussions. Often, the problem has been discussed before, with a resolution that doesn't require a code change, or recording what kind of changes will not be accepted as a resolution.
• Search JIRA for existing issues: https://issues.apache.org/jira/browse/BOOKKEEPER
  Type "bookkeeper [search terms]" at the top right search box. If a logically similar issue already exists, then contribute to the discussion on the existing JIRA and pull request first, instead of creating a new one.
• Is the scope of the change matched to the contributor's level of experience? Anyone is qualified to suggest a typo fix, but refactoring recovery logic requires much more understanding of BookKeeper. Some changes require building up experience first (see above).

Code Review Criteria

Before considering how to contribute code, it's useful to understand how code is reviewed, and why changes may be rejected. Simply put, changes that have many or large positives, and few negative effects or risks, are much more likely to be merged, and merged quickly. Risky and less valuable changes are very unlikely to be merged, and may be rejected outright rather than receive iterations of review.

Positives

• Fixes the root cause of a bug in existing functionality
• Adds functionality or fixes a problem needed by a large number of users
• Simple, targeted
• Has tests
• Reduces complexity and lines of code
• Change has already been discussed and is known to committers

Negatives

• Adds complexity that only helps a niche use case
• Changes a public API or semantics (rarely allowed)
• Makes lots of modifications in one "big bang" change
• Band-aids a symptom of a bug only

Contributing Code Changes

Please review the preceding section before proposing a code change. This section documents how to do so.

JIRA

1. Find the existing BookKeeper JIRA ticket that the change pertains to.
   1. Do not create a new JIRA ticket if creating a change to address an existing ticket in JIRA; add to the existing discussion and work instead.
   2. To avoid conflicts, assign the JIRA ticket to yourself if you plan to work on it.
   3. Look for existing pull requests or review boards that are linked from the the JIRA ticket, to understand if someone is already working on it.
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 javadoc"
3. If required, create a new JIRA ticket:
   1. Provide a descriptive Title. "Update web UI" or "Problem in ledger storage" is not sufficient. "Potential resource leak with unclosed LedgerManager in BookieShell" 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 link to mailing list discussion.
   3. Set required fields:
      1. Issue Type. Generally, Bug, Improvement, New Feature, Documentation are the only types used in BookKeeper.
      2. Priority. Set to Major or below; higher priorities are generally reserved for committers to set. JIRA tends to unfortunately conflate "size" and "importance" in its Priority field values. Their meaning is roughly:

         1. Blocker: pointless to release without this change as the release would be unusable to a large minority of users

         2. Critical: a large minority of users are missing important functionality without this, and/or a workaround is difficult

         3. Major: a small minority of users are missing important functionality without this, and there is a workaround

         4. Minor: a niche use case is missing some support, but it does not affect usage or is easily worked around

         5. Trivial: a nice-to-have change but unlikely to be any problem in practice otherwise
            

      3. Component
      4. Affects Version. For Bugs, assign at least one version that is known to exhibit the problem or need the change.
   4. To avoid conflicts, assign the JIRA ticket to yourself if you plan to work on it. Leave it unassigned otherwise.
      
4. If the change is a large change, consider inviting discussion on the issue at dev@bookkeeper.apache.org first before proceeding to implement the change.
   

Review Board Workflow

1. Create local branch from master.

   Code Block
   $ git checkout -b BOOKKEEPER-XXXX

   
   

2. Make your modifications, add tests and run the whole test suite.
3. Commit your changes.
   

4. Generate a patch.

   Code Block
   $ git format-patch --no-prefix master

   
   

5. Upload the patch to JIRA.
6. If the patch is non-trivial, also upload it to review board under bookkeeper-git.
7. Click on Patch Available in JIRA to signal that the patch is ready to be reviewed.
8. The jenkin build will build the patch and run various checks like long lines, trailing spaces, findbugs. The pre-commit build report will be posted as a comment to the ticket. Please watch the comment and address the failures observed in pre-commit job and iterator over them.
   

Git Workflow

Pull Request

The Review Process

Closing Your Pull Request / JIRA

(WIP)