Page History

...

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.
   

...