+
+Review moderation and guidelines
+--------------------------------
+
+Once a change is submitted, reviewers shall review the change. This may require
+several iterations before a merge. Comments from reviewers may include
+questions, and requests for alterations to the change prior to merging. The
+overarching philosophy in managing this process is that there should be
+politeness and clear communication between all parties at all times, and,
+whenever possible, permission should be asked before doing anything that may
+inconvenience another party. Included below are some guidelines we expect
+contributors and reviewers to follow.
+
+ * In all forms of communication, contributors and reviewers must be polite.
+ Comments seen as being needlessly hostile or dismissive will not be
+ tolerated.
+ * Change contributors should respond to, or act upon, each item of feedback
+ given by reviewers. If there is disagreement with a piece of
+ feedback, a sufficiently detailed reason for this disagreement should
+ be given. Polite discussion, and sharing of information and expertise
+ is strongly encouraged.
+ * Contributors are advised to assign reviewers when submitting a change.
+ Anyone who contributes to gem5 can be assigned as a reviewer. However,
+ all changes must be accepted by at least one maintainer prior to a
+ merge, ergo assigning of at least one maintainer as a reviewer is
+ strongly recommended. Please see MAINTAINERS for a breakdown of
+ gem5 maintainers and which components they claim responsibility for.
+ Maintainers should be chosen based on which components the change is
+ targeting. Assigning of reviewers is not strictly enforced, though not
+ assigning reviewers may slow the time in which a change is reviewed.
+ * If a contributor posts a change and does not receive any reviews after two
+ working days (excluding regional holidays), it is acceptable to "prod"
+ reviewers. This can be done by adding a reply to the changeset review
+ (e.g., "Would it be possible for someone to review my change?"). If the
+ contributor has yet to assign reviewers, they are strongly advised to do so.
+ Reviewers will get notified when assigned to referee a change.
+ * By default, the original contributor is assumed to own a change. I.e.,
+ they are assumed to be the sole party to submit patchsets. If someone
+ other than the original contributor wishes to submit patchsets to a
+ change on the original contributor's behalf, they should first ask
+ permission. If two working days pass without a response, a patchset may be
+ submitted without permission. Permission does not need to be asked to submit
+ a patchset consisting of minor, inoffensive, changes such a typo and format
+ fixes.
+ * Once a change is ready to merge, it enters a "Ready to Submit" state. The
+ original contributor should merge their change at this point, assuming they
+ are content with the commit in its present form. After two working days, a
+ reviewer may message a contributor to remind them of the change being in a
+ "Ready to Submit" state and ask if they can merge the change on the
+ contributors behalf. If a further two working days elapse without a
+ response, the reviewer may merge without permission. A contributor may keep
+ a change open for whatever reason though this should be communicated to the
+ reviewer when asked.
+ * After a month of inactivity from a contributor on an active change, a
+ reviewer may post a message on the change reminding the submitter, and
+ anyone else watching the change, of its active status and ask if they are
+ still interested in eventually merging the change. After two weeks of no
+ response the reviewer reserves the right to abandon the change under the
+ assumption there is no longer interest.
+ * The final arbiter in any dispute between reviewers and/or contributors
+ is the PMC (PMC members are highlighted in MAINTAINERS). Disputes requiring
+ intervention by the PMC are undesirable. Attempts should be made to resolve
+ disagreements via respectful and polite discourse before being escalated to
+ this level.
+
+Releases
+========
+
+gem5 releases occur 3 times per year. The procedure for releasing gem5 is as
+follows:
+
+1. Developers will be notified, via the gem5-dev mailing list, that a new
+release of gem5 will occur. This should be no sooner than 2 weeks prior to the
+creation of the staging branch (the first step in releasing a new version of
+gem5). This gives time for developers to ensure their changes for the next
+release are submitted to the develop branch.
+2. When a release is ready, a new staging branch shall be created by a project
+maintainer, from develop, with the name "release-staging-{VERSION}". The
+gem5-dev mailing list will be notified that the staging branch will be merged
+into the master branch after two weeks, thus marking the new release.
+3. The staging branch will have the full suite of gem5 tests run on it to
+ensure all tests pass and the to-be-released code is in a decent state.
+4. If a user submits a changeset to the staging branch, it will be considered
+and undergo the standard Gerrit review process. However, only alterations that
+cannot wait until the following release will be accepted for submission into
+the branch (i.e., submissions to the staging branch for "last minute"
+inclusions to the release should be of a high priority, such as a critical bug
+fix). The project maintainers will use their discretion in deciding whether a
+change may be submitted directly to the staging branch. All other submissions
+to gem5 will continue to be made to the develop branch. Patches submitted
+into the staging branch do not need to be re-added to the develop branch.
+5. Once signed off by members of the PMC the staging branch shall be merged
+into the master and develop branch. The staging branch will then be deleted.
+6. The master branch shall be tagged with the correct version number for that
+release. gem5 conforms to a "v{YY}.{MAJOR}.{MINOR}.{HOTFIX}" versioning system.
+E.g., the first major release of 2022 will be "v22.0.0.0", followed by
+"v22.1.0.0". All the releases (with the exception of hotfixes) are considered
+major releases. For the meantime, there are no minor releases though we keep
+the minor release numbers in case this policy changes in the future.
+7. The gem5-dev and gem5-user mailing lists shall be notified of the new gem5
+release.
+
+Hotfixes
+--------
+
+There may be circumstances in which a change to gem5 is deemed critical and
+cannot wait for an official release (e.g., a high-priority bug fix). In these
+circumstances a hotfix shall be made.
+
+First, if a developer suspects a hotfix may be necessary then the issue
+should be discussed on the gem5-dev mailing list. The community will decide
+whether the issue is worthy of a hotfix, and the final decision should be
+made by members of the PMC if there is no consensus. Assuming the hotfix is
+permitted, the following steps will be taken:
+
+1. A new branch with the prefix "hotfix-" will be created from the master
+branch. Only gem5 maintainers can create branches. If a non-maintainer requires
+the creation of a hotfix branch then they should contact a gem5 maintainer.
+2. The change shall be submitted to the hotfix branch via gerrit. Full review,
+as with any other change, will be required.
+3. Once fully submitted, the hotfix branch shall be merged into both the
+develop and the master branch by a gem5 maintainer.
+4. The master branch will be tagged with the new version number; the same as
+the last but with an incremented hotfix number (e.g., "v20.2.0.0" would
+transition to "v20.2.0.1").
+4. The hotfix branch will then be deleted.
+5. The gem5-dev and the gem5-user mailing lists shall be notified of this
+hotfix.