summaryrefslogtreecommitdiffstats
path: root/Documentation/dev-core-plugins.txt
blob: ffce6c231e69e88fc4904451df209ce9555aa8de (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
:linkattrs:
= Gerrit Code Review - Core Plugins

[[definition]]
== What are core plugins?

Core plugins are plugins that are packaged within the Gerrit war file. This
means during the link:pgm-init.html[Gerrit initialization] they can be easily
installed without downloading any additional files.

To make working with core plugins easy, they are linked as
link:https://gerrit.googlesource.com/gerrit/+/refs/heads/master/.gitmodules[Git
submodules,role=external,window=_blank] in the `gerrit` repository. E.g. this means they can be easily
link:dev-readme.html#clone[cloned] together with Gerrit.

All core plugins are developed and maintained by the
link:dev-roles.html#maintainers[Gerrit maintainers] and everyone can
link:dev-contributing.html[contribute] to them.

Adding a new core plugin feature that is large or complex requires a
link:dev-design-doc.html[design doc] (also see
link:dev-contributing.html#design-driven-contribution-process[design-driven
contribution process]). The link:dev-processes.html#steering-committee[
engineering steering committee (ESC)] is the authority that approves the design
docs. The ESC is also in charge of adding and removing core plugins.

Non-Gerrit maintainers cannot have link:access-control.html#category_owner[
Owner] permissions for core plugins.

[[list]]
== Which core plugins exist?

See link:config-plugins.html#core-plugins[here].

[[criteria]]
=== Criteria for Core Plugins

To be considered as a core plugin, a plugin must fulfill the following
criteria:

1. License:
+
The plugin code is available under the
link:http://www.apache.org/licenses/LICENSE-2.0[Apache License Version 2.0,role=external,window=_blank].

2. Hosting:
+
The plugin development is hosted on the
link:https://gerrit-review.googlesource.com[gerrit-review,role=external,window=_blank] Gerrit Server.

3. Scope:
+
The plugin functionality is Gerrit-related, has a clear scope and does not
conflict with other core plugins or existing and planned Gerrit core features.

4. Relevance:
+
The plugin functionality is relevant to a majority of the Gerrit community:
+
--
** An out of the box Gerrit installation would seem like it is missing
   something if the plugin is not installed.
** It's expected that most sites would use the plugin.
** Multiple parties (different organizations/companies) already use the plugin
   and agree that it should be offered as core plugin.
** If the same or similar functionality is provided by multiple plugins,
   the plugin is the clear recommended solution by the community.
--
+
Whether a plugin is relevant to a majority of the Gerrit community must be
discussed on a case-by-case basis. In case of doubt, it's up to the
link:dev-processes.html#steering-committee[engineering steering committee] to
make a decision.

5. Code Quality:
+
The plugin code is mature and has a good test coverage. Maintaining the plugin
code creates only little overhead for the Gerrit maintainers.

6. Documentation:
+
The plugin functionality is fully documented.

7. Ownership:
+
Existing plugin owners which are not Gerrit maintainers must agree to give up
their ownership. If the current plugin owners disagree, forking the plugin is
possible, but this should happen only in exceptional cases.

[[process-to-make-a-plugin-a-core-plugin]]
== Process to make a plugin a core plugin

Anyone can propose to make a plugin a core plugin, but to be accepted as core
plugin the plugin must fulfill certain link:#criteria[criteria].

1. Propose a plugin as core plugin:
+
File a link:https://issues.gerritcodereview.com/issues/new?component=1371029&template=1834214[
Core Plugin Request] in the issue tracker and provide the information that is
being asked for in the request template.

2. Community Feedback:
+
Anyone can comment on the issue to raise concerns or to support the request.
The issue should stay open for at least 10 calendar days so that everyone in
the community has a chance to comment.

3. ESC Decision:
+
The ESC should discuss the request and reject/approve it or ask for further
information that the reporter or commenters should provide.
+
Any decision must be based on the link:#criteria[criteria] that core plugins
are expected to fulfill and should take the feedback from the community into
account.
+
Accepting the request is only possible if the issue was open for at least 10
calendar days (see 2., this gives the community time to comment).
+
When the ESC approves/rejects the request a summary of the reasons for the
decision should be added to the issue.
+
If a request is rejected, it's possible to ask for a revalidation if the
concerns that led to the rejection have been addressed (e.g. the plugin was
rejected due to missing tests, but tests have been added afterwards).

4. Add plugin as core plugin:
+
If the request was accepted, a Gerrit maintainer should add the plugin as
core plugin:
+
--
** Host the plugin repo on link:https://gerrit-review.googlesource.com/[
   gerrit-review].
** Ensure that the plugin repo inherits from the
   link:https://gerrit-review.googlesource.com/admin/repos/Public-Plugins[
   Public-Plugins] repo.
** Remove all permissions on the plugin repo (the inherited permissions from
   `Public-Plugins` should be enough). Especially make sure that there are no
   link:access-control.html#category_owner[Owner],
   link:access-control.html#category_push_direct[Direct Push],
   link:access-control.html#category_submit[Submit] or
   link:access-control.html#category_review_labels[Code-Review+2]
   permissions for non-Gerrit maintainers.
** Create a component for the plugin in
   link:https://bugs.chromium.org/p/gerrit/adminComponents[Monorail] and assign
   all issues that already exist for the plugin to this component.
** Add the plugin as
   link:https://gerrit.googlesource.com/gerrit/+/refs/heads/master/.gitmodules[Git
   submodule].
** Register the plugin as core plugin in
   link:https://gerrit.googlesource.com/gerrit/+/refs/heads/master/tools/bzl/plugins.bzl[
   plugins.bzl].
** Announce the new core plugin in the
   link:https://www.gerritcodereview.com/news.html[project news].
--

[[removing]]
=== Removing Core Plugins

A core plugin could be subject to NOT be considered core anymore if:

1. Does not respect the license:
+
The plugin code or the libraries used are not following anymore the
Apache License Version 2.0.

2. Is out of scope:
+
The plugin functionality has gone outside the Gerrit-related scope,
has a clear scope or conflict with other core plugins or existing and
planned Gerrit core features.
+
NOTE: The plugin would need to remain core until the planned replacement gets
implemented. Otherwise the feature is likely missing between the removal and
planned implementation times.

3. Is not relevant:
+
The plugin functionality is no more relevant to a majority of the Gerrit community:
+
--
** An out of the box Gerrit installation won’t be missing anything if the plugin is
   not installed.
** It isn’t anymore used by most sites.
** Multiple parties (different organizations/companies) have abandoned the use of
   the plugin and agree that it should not be anymore a core plugin.
** If the same or similar functionality is provided by multiple plugins, the plugin
   is not a clear recommended solution anymore by the community.
** Whether a plugin is no more relevant to a majority of the Gerrit community must be
   discussed on a case-by-case basis. In case of doubt, it’s up to the engineering
   steering committee to make a decision.
--

4. Degraded code quality:
+
The plugin code maintenance is lacking and has not anymore good test coverage.
Maintaining the plugin code creates a significant overhead for the Gerrit maintainers.

5. Outdated documentation:
+
The plugin functionality documented is significantly outdated.

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

SEARCHBOX
---------