Jump to: navigation, search


< StarlingX
Revision as of 22:14, 28 September 2018 by Ghada.khalil (talk | contribs)

StarlingX Code Submission Guidelines

  • Use Gerrit for StarlingX code reviews
  • Follow the Openstack Git Commit Good Practice here
  • Add the core reviewers for the affected sub-project to the review
    • The core reviewers are listed on each sub-project wiki pages. The list of sub-projects is available here
  • All code changes must be pushed to master first and then cherry-picked to the appropriate release branch as needed
    • Exception: Feature branches used during development
  • Link your code change to a StoryBoard Story or Launchpad Bug
    • For traceability, always link your code change to a story or bug. Gerrit will update the status of the story/bug automatically once the code is merged.
    • Linking to StoryBoard Stories: Specify the story and task ID in the commit message as follows:
    • Linking to Launchpad Bugs: Specify the Bug ID in the commit message as follows:
      • Closes-Bug: $bug_id -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced.
      • Partial-Bug: $bug_id -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed.
      • Related-Bug: $bug_id -- use 'Related-Bug' if the commit is merely related to the referenced bug.
      • If a fix requires multiple commits, use "Partial-Bug" with only the final commit using "Closes-Bug"
      • Example: https://review.openstack.org/596305
  • Pre-Submission / Pre-Gerrit Testing
    • At a minimum, make sure the code builds and runs
    • Verify basic functional testing on a builtISO (ensure the new code get executed)
    • Include automated unit tests when applicable. As we build out the Zuul infrastructure, those tests will run per merge
    • If needed, consult with the component core reviewers for any required/recommended testing.
    • Code reviewers should ask about testing details as part of the gerrit code inspection.