6cc26d29e7
A number of the links from these slides were no longer accurate. This patch set fixes those links. Note that link for the commit message slide is set based on the new patchset that is currently under review for those slides. It also updates the wording on a number of the slides for clarity. A note is also added that they may need to use 'git-review' instead of 'git review' depending on the environment they are doing development in. Change-Id: Ibd7405f062ab2b119fba21ebb7f8138455f7fab3
9.2 KiB
9.2 KiB
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