= Gerrit Code Review - Development Processes

[[project-governance]]
[[steering-committee]]
== Project Governance / Engineering Steering Committee

The Gerrit project has an engineering steering committee (ESC) that is
in charge of:

* Gerrit core (the `gerrit` project) and the core plugins
* defining the project vision and the project scope
* maintaining a roadmap, a release plan and a prioritized backlog
* ensuring timely design reviews
* ensuring that new features are compatible with the project vision and
  are well aligned with other features (give feedback on new
  link:dev-design-docs.html[design docs] within 14 calendar days)
* approving/rejecting link:dev-design-docs.html[designs], vetoing new
  features
* assigning link:dev-roles.html#mentor[mentors] for approved features
* accepting new plugins as core plugins
* making changes to the project governance process and the
  link:dev-contributing.html#contribution-processes[contribution
  processes]

The steering committee has 5 members:

* 3 Googlers that are appointed by Google
* 2 non-Google maintainers, elected by non-Google maintainers for the
  period of 1 year (see link:#steering-committee-election[below])

Refer to the project homepage for the link:https://www.gerritcodereview.com/esc.html[
list of current committee members].

The steering committee should act in the interest of the Gerrit project
and the whole Gerrit community.

For decisions, consensus between steering committee members and all
other maintainers is desired. If consensus cannot be reached, decisions
can also be made by simple majority in the steering committee (should
be applied only in exceptional situations).

The steering committee is empowered to overrule positive/negative votes
from individual maintainers, but should do so only in exceptional
situations after attempts to reach consensus have failed.

As an integral part of the Gerrit community, the steering committee is
committed to transparency and to answering incoming requests in a
timely manner.

[[steering-committee-election]]
=== Election of non-Google steering committee members

The election of the non-Google steering committee members happens once
a year in May. Non-Google link:dev-roles.html#maintainer[maintainers]
can nominate themselves by posting an informal application on the
non-public maintainers mailing list by end of April (deadline for 2019
is Mon 13th of May). By applying to be steering committee member, the
candidate confirms to be able to dedicate the time that is needed to
fulfill this role (also see
link:dev-roles.html#steering-committee-member[steering committee
member]).

Each non-Google maintainer can vote for 2 candidates. The voting
happens by posting on the maintainer mailing list. The voting period is
14 calendar days from the nomination deadline (except for 2019, where
the initial steering committee should be confirmed during the Munich
hackathon, the voting period goes from 14th May to 16th May).

Google maintainers do not take part in this vote, because Google
already has dedicated seats in the steering committee (see section
link:steering-committee[steering committee]).

[[contribution-process]]
== Contribution Process

See link:dev-contributing.html[here].

[[design-doc-review]]
== Design Doc Review

See link:dev-design-docs.html#review[here].

[[versioning]]
== Semantic versioning

Gerrit follows a light link:https://semver.org/[semantic versioning scheme] MAJOR.MINOR[.PATCH[.HOTFIX]]
format:

  * MAJOR is incremented when there are substantial incompatible changes and/or
    new features in Gerrit.
  * MINOR is incremented when there are changes that are typically backward compatible
    with the earlier minor version. Features can be removed following the
    link:#deprecating-features[feature deprecation process]. Dependencies can be upgraded
    according to the link:dev-processes.html#upgrading-libraries[libraries upgrade policy].
  * PATCH is incremented when there are backward-compatible bug fixes in Gerrit or its
    dependencies. When PATCH is zero, it can be omitted.
  * HOTFIX is present only when immediately after a patch release, some urgent
    fixes in the code or the packaging format are required but do not justify a
    new patch release.

For every MAJOR.MINOR release there is an associated stable branch that follows well defined
link:#dev-in-stable-branches[rules of development].

Within a stable branch, there are multiple MAJOR.MINOR.PATCH tags created associated to the
bug-fix releases of that stable release.

Examples:

* Gerrit v3.0.0 contains breaking incompatible changes in the functionality because
  the ReviewDb storage has been totally removed.
* Gerrit v2.15 contains brand-new features like NoteDb, however, still supports the existing
  ReviewDb storage for changes and thus is considered a minor release.
* Gerrit v2.14.20 is the 20th patch-release of the stable Gerrit v2.14.* and thus does not contain
  new features but only bug-fixes.

[[dev-in-stable-branches]]
== Development in stable branches

As their name suggests stable branches are intended to be stable. This means that generally
only bug-fixes should be done on stable branches, however this is not strictly enforced and
exceptions may apply:

  * When a stable branch is initially created to prepare a new release the Gerrit community
    discusses on the mailing list if there are pending features which should still make it into the
    release. Those features are blocking the release and should be implemented on the stable
    branch before the first release candidate is created.
  * To stabilize the code before doing a major release several release candidates are created. Once
    the first release candidate was done no more features should be accepted on the stable branch.
    If more features are found to be required they should be discussed with the steering committee
    and should only be allowed if the risk of breaking things is considered to be low.
  * Once a major release is done only bug-fixes and documentation updates should be done on the
    stable branch. These updates will be included in the next minor release.
  * For minor releases new features could be acceptable if the following conditions are met:
    ** they are result of a new feature introduced through a merge of an earlier stable branch
    ** they are justified for completing, extending or fixing an existing feature
    ** does not involve API, user-interface changes or data migrations
    ** is backward compatible with all existing features
    ** the parts of the code in common with existing features are properly covered by end-to-end tests
    ** is important to the Gerrit community and no Gerrit maintainers have raised objections.
  * In cases of doubt or conflicting opinions on new features, it's the responsibility of the
    steering committee to evaluate the risk of new features and make a decision based on these
    rules and opinions from the Gerrit community.
  * The older a stable branch is the more stable it should be. This means old stable branches
    should only receive bug-fixes that are either important or low risk. Security fixes, including
    security updates for third party dependencies, are always considered as important and hence can
    always be done on stable branches.

Examples:

* Gerrit v3.0.0-rc1 and v3.0.0-rc2 may contain new features and API changes without notice,
  even if they are both cut on the same stable-3.0 branch.
* Gerrit v2.14.8 introduced the support for ElasticSearch as a new feature. This was an exception
  agreed amongst the Gerrit maintainers, did not touch the Lucene indexing code-base, was supported
  by container-based E2E tests and represents a completion of an high-level feature.

[[backporting]]
== Backporting to stable branches

From time to time bug fix releases are made for existing stable branches.

Developers concerned with stable branches are encouraged to backport or push fixes to these
branches, even if no new release is planned. Backporting features is only possible in compliance
with the rules link:#dev-in-stable-branches[above].

Fixes that are known to be needed for a particular release should be pushed for review on that
release's stable branch. They will then be included into the master branch when the stable branch
is merged back.

[[upgrading-libraries]]
== Upgrading Libraries

Changes that add new libraries or upgrade existing libraries require an approval on the
`Library-Compliance` label. For an approval the following things are checked:

* The library has a license that is suitable for use within Gerrit.
* If the library is used within Google, the version of the library must be compatible with the
  version that is used at Google.

Only maintainers from Google can vote on the `Library-Compliance` label.

Gerrit's library dependencies should only be upgraded if the new version contains
something we need in Gerrit. This includes new features, API changes as well as bug
or security fixes.
An exception to this rule is that right after a new Gerrit release was branched
off, all libraries should be upgraded to the latest version to prevent Gerrit
from falling behind. Doing those upgrades should conclude at the latest two
months after the branch was cut. This should happen on the master branch to ensure
that they are vetted long enough before they go into a release and we can be sure
that the update doesn't introduce a regression.

[[deprecating-features]]
== Deprecating features

Gerrit should be as stable as possible and we aim to add only features that last.
However, sometimes we are required to deprecate and remove features to be able
to move forward with the project and keep the code-base clean. The following process
should serve as a guideline on how to deprecate functionality in Gerrit. Its purpose
is that we have a structured process for deprecation that users, administrators and
developers can agree and rely on.

General process:

  * Make sure that the feature (e.g. a field on the API) is not needed anymore or blocks
    further development or improvement. If in doubt, consult the mailing list.
  * If you can provide a schema migration that moves users to a comparable feature, do
    so and stop here.
  * Mark the feature as deprecated in the documentation and release notes.
  * If possible, mark the feature deprecated in any user-visible interface. For example,
    if you are deprecating a Git push option, add a message to the Git response if
    the user provided the option informing them about deprecation.
  * Annotate the code with `@Deprecated` and `@RemoveAfter(x.xx)` if applicable.
    Alternatively, use `// DEPRECATED, remove after x.xx` (where x.xx is the version
    number that has to be branched off before removing the feature)
  * Gate the feature behind a config that is off by default (forcing admins to turn
    the deprecated feature on explicitly).
  * After the next release was branched off, remove any code that backed the feature.

You can optionally consult the mailing list to ask if there are users of the feature you
wish to deprecate. If there are no major users, you can remove the feature without
following this process and without the grace period of one release.

GERRIT
------
Part of link:index.html[Gerrit Code Review]

SEARCHBOX
---------