|
|
v
- +------+------+
- | Post review |
- +------+------+
- |
- v
- +--------+---------+
- | Wait for reviews | <--------+
+ +-------------+
+ | Run tests |<--------------+
+ +------+------+ |
+ | |
+ | |
+ v |
+ +------+------+ |
+ | Post review | |
+ +------+------+ |
+ | |
+ v |
+ +--------+---------+ |
+ | Wait for reviews | |
+--------+---------+ |
| |
| |
community. Additionally, the maintainer for that part of the code must sign off
on it.
+Contributing long-lived feature branches
+----------------------------------------
+Oftentimes users or institutions add features that are necessarily complex,
+and require many changes on long-lived feature branches. In this case,
+maintaining a perfect history where all changes work individually is infeasible.
+When contributing long-lived feature branches back to gem5's public repository
+users may merge entire long-lived branches into a single changeset and contribute
+their code back as long as 1) the changes have been reviewed by the maintainer
+2) the maintainer agrees to allow such a change, and 3) the changes are passing
+the public tests. Changes that affect common code (outside of a specific
+maintainer's purview) will still need to follow the standard gem5 protocol.
+
+
Cloning the gem5 repo to contribute
===================================
https://gem5.googlesource.com/.
To clone the master gem5 repository:
- > git clone https://gem5.googlesource.com/public/gem5
+```
+ git clone https://gem5.googlesource.com/public/gem5
+```
Other gem5 repositories
-----------------------
A canonical commit message consists of three parts:
* A short summary line describing the change. This line starts with one or
- more keywords separated by commas followed by a colon and a description of
- the change. This line should be no more than 65 characters long since
- version control systems usually add a prefix that causes line-wrapping for
- longer lines.
+ more keywords (found in the MAINTAINERS file) separated by commas followed
+ by a colon and a description of the change. This line should be no more than
+ 65 characters long since version control systems usually add a prefix that
+ causes line-wrapping for longer lines.
* (Optional, but highly recommended) A detailed description. This describes
what you have done and why. If the change isn't obvious, you might want to
motivate why it is needed. Lines need to be wrapped to 75 characters or
tags to acknowledge reviewers for their work. Gerrit will automatically add
most tags.
-The keyword should be one or more of the following separated by commas:
- * Architecture name in lower case (e.g., arm or x86): Anything that is
- target-architecture specific.
- * base
- * ext
- * stats
- * sim
- * syscall_emul
- * config:
- * mem: Classic memory system. Ruby uses its own keyword.
- * ruby: Ruby memory models.
- * cpu: CPU-model specific (except for kvm)
- * kvm: KVM-specific. Changes to host architecture specific components should
- include an architecture keyword (e.g., arm or x86) as well.
- * gpu-compute
- * energy
- * dev
- * arch: General architecture support (src/arch/)
- * scons: Build-system related. Trivial changes as a side effect of doing
- something unrelated (e.g., adding a source file to a SConscript) don't
- require this.
- * tests
- * style: Changes to the style checkers of style fixes.
- * misc
-
Tags are an optional mechanism to store additional metadata about a patch and
acknowledge people who reported a bug or reviewed that patch. Tags are
generally appended to the end of the commit message in the order they happen.
It is imperative that you use your real name and your real email address in
both tags and in the author field of the changeset.
+For significant changes, authors are encouraged to add copyright information
+and their names at the beginning of the file. The main purpose of the author
+names on the file is to track who is most knowledgeable about the file (e.g.,
+who has contributed a significant amount of code to the file).
+
Note: If you do not follow these guidelines, the gerrit review site will
automatically reject your patch.
If this happens, update your changeset descriptions to match the required style
and resubmit. The following is a useful git command to update the most recent
commit (HEAD).
- > git commit --amend
+```
+ git commit --amend
+```
+
+Running tests
+=============
+
+Before posting a change to the code review site, you should always run the
+quick tests!
+See TESTING.md for more information.
Posting a review
================
Push change to gerrit review
----------------------------
- > git push origin HEAD:refs/for/master
+```
+ git push origin HEAD:refs/for/master
+```
Assuming origin is https://gem5.googlesource.com/public/gem5 and you want to
push the changeset at HEAD, this will create a new review request on top of the
master branch. More generally,
- > git push <gem5 gerrit instance> <changeset>:refs/for/<branch>
+```
+ git push <gem5 gerrit instance> <changeset>:refs/for/<branch>
+```
See https://gerrit-review.googlesource.com/Documentation/user-upload.html for
more information.
--------------------------
The first time you push a change you may get the following error:
- > remote: ERROR: [fb1366b] missing Change-Id in commit message footer
- > ...
+```
+ remote: ERROR: [fb1366b] missing Change-Id in commit message footer
+ ...
+```
Within the error message, there is a command line you should run. For every new
clone of the git repo, you need to run the following command to automatically
insert the change id in the the commit (all on one line).
- > curl -Lo `git rev-parse --git-dir`/hooks/commit-msg
- https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x
- `git rev-parse --git-dir`/hooks/commit-msg
+```
+ curl -Lo `git rev-parse --git-dir`/hooks/commit-msg \
+ https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; \
+ chmod +x `git rev-parse --git-dir`/hooks/commit-msg
+```
If you receive the above error, simply run this command and then amend your
changeset.
- > git commit --amend
+```
+ git commit --amend
+```
+
+Push change to gerrit as a draft/private
+----------------------------------------
+
+See https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
+for details on private gerrit changes.
-Push change to gerrit as a draft
---------------------------------
+```
+ git push origin HEAD:refs/for/master%private
+```
- > git push origin HEAD:refs/drafts/master
+Once you have pushed your change as "private", you can log onto [gerrit]
+(https://gem5-review.googlesource.com) and once you're happy with the commit
+click the "unmark private" which may be hidden in the "more options" dropdown
+in the upper right corner.
Push change bypassing gerrit
-----------------------------
Only maintainers can bypass gerrit review. This should very rarely be used.
- > git push origin HEAD:refs/heads/master
+```
+ git push origin HEAD:refs/heads/master
+```
Other gerrit push options
-------------------------
can simply push the changeset again to the same Gerrit branch to update the
review request.
- > git push origin HEAD:refs/for/master
+```
+ git push origin HEAD:refs/for/master
+```
Note: If you have posted a patch and don't receive any reviews, you may need to
prod the reviewers. You can do this by adding a reply to your changeset review
projects / gem5.git / blobdiff