Using Sandbox for Practice
Sandbox repository
- OpenStack has a sandbox repository for learning and testing purposes
- Great repository to begin your OpenStack learning
Sandbox Launchpad
- To manage and track the reported bugs and issues related with openstack-dev/sandbox repository
Learning example with two Sandboxes
- The following slides demonstrate using the Sandbox repository
and Launchpad to:
- Report a bug on Launchpad
- Read the bug description and assign yourself to fix the bug
- Upload a patch and invite a peer as a reviewer
- Review the patch and give feedback with comments
- Upload a revised patch with comment
- Review the revised patch and merge the patch
Note
- Try to emphasize the synergy of using repository integration with bug management to students!
Sandbox Launchpad Bug list
Report a bug - Summary
- We have seen in Overview of the contribution process
- https://bugs.launchpad.net/openstack-dev-sandbox/+filebug
Report a bug - Details
- (A real bug report needs a more detailed description.)
Note
- Detailed description should include the OpenStack release that was running, log snippets showing the error, steps to recreate the error and any vendor hardware possibly involved.
- Details need to be sufficient for a developer to narrow down where the failure occurred and/or recreate the failure.
Bug Report Submission
- Successful bug report submission
Bug Assigning
- To notify others that someone is working on the bug
Note
- Should not take the bug if you are not planning to work on the bug.
Bug Assigned
- (Other people will assume the person is working on the bug.)
Local branch creation
- We have seen in Setup & First patch
$ git checkout -b [BRANCH_NAME]
Working to get a commit
- (As an example, a new file has been created using cat command.)
Checking work status
- Current branch name information
- File status in the working repository
$ git status
Add the file and commit
$ git add [FILE_PATH]
$ git commit -a
- Writing 'Related-Bug: #[Bug number in Lanuchpad]' on message content
- We have seen in Commit Messages
Commit log message
- (Checking the log message before uploading is a best practice.)
$ git log
Uploading to Gerrit
$ git review master
(Note: In some environments need to use 'git-review master')
Sandbox Status
- Gerrit (openstack-dev/sandbox repository)
- Launchpad (openstack-dev-sandbox)
Invite peer as Reviewer
- We have seen in Gerrit
- (Find reviewer by Gerrit username or e-mail address.)
Added as Reviewer
- (Review invitation letter has been sent by e-mail.)
Reading review invitation
- Review invitation letter
Reviewing with comment
- Commenting
- Draft comment was saved
Publish comment
- (Draft comments are not visible to others.)
Review Score & Results
- Score will reflect reviewer's opinion.
- Results will be accumulated in History.
Check peer's Review
- Review score with written comments
- Do not be frustrated! We can revise the current patchset to address comments.
Revising file(s)
- Start work from latest patchset
Amending the commit
- We have seen in Setup & First Patch
- (Please also change your commit message if needed.)
$ git commit -a --amend
Uploading a new patchset
- Executing "git review" command will submit the amended commit.
- New patchset was recorded in Gerrit.
Seeing new comment
- Since the written comment is in the previous patchset, select patchset 1, and choose the file which has comment(s).
Comment reply
- Answering reviewer's comment(s) is a best practice.
- Click 'Reply' and write your message, or just 'Done' for "Done" message.
Publish comment reply
- Draft comment publishment
- (Ensure that your comment is being shown in History.)
Review again
- Code-Review -1/0/+1 is for all OpenStack reviewers
- Code-Review -2/+2 is for core reviewers (Sandbox repository is open)
- The Gerrit review will be merged by +1 in Workflow
Merged!
- Score status
- History status
Home Work
- You can practice the skills documented in the previous slides.
- Create a few different changes and submit new patchsets to those few changes in the Sandbox repository for one bug in Launchpad.
- Cleaning up activities are needed
- Includes the deletion of uploaded files on Sandbox repository and change of bug status in Launchpad to "Invalid", "Won't Fix", or "Fix Released"
- During upstream training, do not worry about this! Upstream training leaders will clean up after the training is finished.
- However, please keep in mind that it is on your own responsibility.
Note
- Please do not let students create 10 or more changes. (This is not the intention of Sandboxes!)
- http://docs.openstack.org/infra/manual/sandbox.html