f13dfa94c7
Establishing mentorships is part of a proposal from Google to foster a better collaboration within the Gerrit community (see change I27e432cce). In the past common issues with contributing large features have been: * lack of reviews (because no maintainer can take the time that is required to do a thorough review) * lack of quality (due to missing technical guidance) * late rejection (after the implementation was already done and uploaded for code review) These issues should be addressed by offering mentorship. A mentor helps with: * doing timely reviews * providing technical guidance during code reviews * discussing details of the design * ensuring that the quality standards are met (well documented, sufficient test coverage, backwards compatible etc.) Contributors can gain a mentorship if: * the design for the feature has been approved * the contributor is committed to do the implementation Mentors are assigned by the steering committee. The pool of mentors is formed by Gerrit maintainers and contributors that volunteer to serve as mentor. Google is committed to fund 1-2 mentorships at a time, also for features that are not on Google's roadmap. Everyone else in community is welcome to serve as mentor too. It's also possible to only volunteer as mentor for specific features (e.g. features of interest that are upcoming). Google would be happy to get non-Google mentors for features that are done by Google. Mentors may not be available immediately. In this case, the steering committee should include the approved feature into the roadmap or prioritize it in the backlog. This way, it is transparent for the contributor when they can expect to be able to work on the feature with mentor support. Change-Id: I10fa8e92639f3a00d7890f75180c6a93eb2a6f6d Signed-off-by: Edwin Kempin <ekempin@google.com>
178 lines
8.5 KiB
Plaintext
178 lines
8.5 KiB
Plaintext
= Gerrit Code Review - Development Processes
|
|
|
|
[[project-governance]]
|
|
[[steering-committee]]
|
|
== Project Governance / Steering Committee
|
|
|
|
The Gerrit project has a steering committee 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])
|
|
|
|
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].
|
|
|
|
[[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 are only acceptable if they are important to the Gerrit
|
|
community, if they are backwards compatible and the risk of breaking things is low and if there
|
|
are no objections from the steering committee.
|
|
* In cases of doubt 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.
|
|
|
|
[[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
|
|
---------
|