4 The `Neutron Core Reviewer Team <https://review.openstack.org/#/admin/groups/38,members>`_
5 is responsible for many things related to Neutron. A lot of these things include mundane
6 tasks such as the following:
8 * Ensuring the bug count is low
9 * Curating the gate and triaging failures
10 * Working on integrating shared code from projects such as Oslo
11 * Ensuring documentation is up to date and remains relevant
12 * Ensuring the level of testing for Neutron is adequate and remains relevant
14 * Helping new contributors with questions as they peel back the covers of
16 * Answering questions and participating in mailing list discussions
17 * Interfacing with other OpenStack teams and ensuring they are going in the
18 same parallel direction
19 * Reviewing and merging code into the neutron tree
21 In essence, core reviewers share the following common ideals:
23 1. They share responsibility in the project's success.
24 2. They have made a long-term, recurring time investment to improve the
26 3. They spend their time doing what needs to be done to ensure the projects
27 success, not necessarily what is the most interesting or fun.
29 A core reviewer's responsibility doesn't end up with merging code. The above
30 lists are adding context around these responsibilities.
35 As Neutron has grown in complexity, it has become impossible for any one
36 person to know enough to merge changes across the entire codebase. Areas of
37 expertise have developed organically, and it is not uncommon for existing
38 cores to defer to these experts when changes are proposed. Existing cores
39 should be aware of the implications when they do merge changes outside the
40 scope of their knowledge. It is with this in mind we propose a new system
41 built around Lieutenants through a model of trust.
43 In order to scale development and responsibility in Neutron, we have adopted
44 a Lieutenant system. The PTL is the leader of the Neutron project, and
45 ultimately responsible for decisions made in the project. The PTL has
46 designated Lieutenants in place to help run portions of the Neutron project.
47 The Lieutenants are in charge of their own areas, and they can propose core
48 reviewers for their areas as well. The core reviewer addition and removal
49 polices are in place below. The Lieutenants for each system, while responsible
50 for their area, ultimately report to the PTL. The PTL may opt to have regular
51 one on one meetings with the lieutenants. The PTL will resolve disputes in
52 the project that arise between areas of focus, core reviewers, and other
53 projects. Please note Lieutenants should be leading their own area of focus,
54 not doing all the work themselves.
56 As was mentioned in the previous section, a core's responsibilities do not
57 end with merging code. They are responsible for bug triage and gate issues
58 among other things. Lieutenants have an increased responsibility to ensure
59 gate and bug triage for their area of focus is under control.
61 The following are the current Neutron Lieutenants.
63 +------------------------+---------------------------+----------------------+
64 | Area | Lieutenant | IRC nick |
65 +========================+===========================+======================+
66 | API and DB | Akihiro Motoki | amotoki |
67 | +---------------------------+----------------------+
68 | | Henry Gessau | HenryG |
69 +------------------------+---------------------------+----------------------+
70 | Built-In Control Plane | Kevin Benton | kevinbenton |
71 +------------------------+---------------------------+----------------------+
72 | Client | Akihiro Motoki | amotoki |
73 +------------------------+---------------------------+----------------------+
74 | Docs | Edgar Magana | emagana |
75 +------------------------+---------------------------+----------------------+
76 | Infra | Armando Migliaccio | armax |
77 | +---------------------------+----------------------+
78 | | Doug Wiegley | dougwig |
79 +------------------------+---------------------------+----------------------+
80 | L3 | Carl Baldwin | carl_baldwin |
81 +------------------------+---------------------------+----------------------+
82 | Services | Doug Wiegley | dougwig |
83 +------------------------+---------------------------+----------------------+
84 | Testing | Assaf Muller | amuller |
85 +------------------------+---------------------------+----------------------+
87 Some notes on the above:
89 * "Built-In Control Plane" means the L2 agents, DHCP agents, SGs, metadata
91 * The client includes commands installed server side.
92 * L3 includes the L3 agent, DVR, and IPAM.
93 * Services includes FWaaS, LBaaS, and VPNaaS.
94 * Note these areas may change as the project evolves due to code refactoring,
95 new feature areas, and libification of certain pieces of code.
96 * Infra means interactions with infra from a neutron perspective
98 Neutron also consists of several plugins, drivers, and agents that are developed
99 effectively as sub-projects within Neutron in their own git repositories.
100 Lieutenants are also named for these sub-projects to identify a clear point of
101 contact and leader for that area. The Lieutenant is also responsible for
102 updating the core review team for the sub-project's repositories.
104 +------------------------+---------------------------+----------------------+
105 | Area | Lieutenant | IRC nick |
106 +========================+===========================+======================+
107 | dragonflow | Eran Gampel | gampel |
108 | +---------------------------+----------------------+
109 | | Gal Sagie | gsagie |
110 +------------------------+---------------------------+----------------------+
111 | kuryr | Antoni Segura Puimedon | apuimedo |
112 | +---------------------------+----------------------+
113 | | Gal Sagie | gsagie |
114 +------------------------+---------------------------+----------------------+
115 | networking-bgpvpn | Mathieu Rohon | matrohon |
116 | +---------------------------+----------------------+
117 | | Thomas Morin | tmorin |
118 +------------------------+---------------------------+----------------------+
119 | networking-calico | Neil Jerram | neiljerram |
120 +------------------------+---------------------------+----------------------+
121 | networking-infoblox | John Belamaric | johnbelamaric |
122 +------------------------+---------------------------+----------------------+
123 | networking-l2gw | Sukhdev Kapur | sukhdev |
124 +------------------------+---------------------------+----------------------+
125 | networking-midonet | Ryu Ishimoto | ryu25 |
126 | +---------------------------+----------------------+
127 | | Jaume Devesa | devvesa |
128 | +---------------------------+----------------------+
129 | | YAMAMOTO Takashi | yamamoto |
130 +------------------------+---------------------------+----------------------+
131 | networking-odl | Flavio Fernandes | flaviof |
132 | +---------------------------+----------------------+
133 | | Kyle Mestery | mestery |
134 +------------------------+---------------------------+----------------------+
135 | networking-ofagent | YAMAMOTO Takashi | yamamoto |
136 +------------------------+---------------------------+----------------------+
137 | networking-onos | Vikram Choudhary | vikram |
138 | +---------------------------+----------------------+
139 | | Albert Dongfeng | albert_dongfeng |
140 +------------------------+---------------------------+----------------------+
141 | networking-ovn | Russell Bryant | russellb |
142 +------------------------+---------------------------+----------------------+
143 | networking-plumgrid | Fawad Khaliq | fawadkhaliq |
144 +------------------------+---------------------------+----------------------+
145 | networking-sfc | Cathy Zhang | cathy |
146 +------------------------+---------------------------+----------------------+
147 | networking-vshpere | Vivekanandan Narasimhan | viveknarasimhan |
148 +------------------------+---------------------------+----------------------+
149 | octavia | German Eichberger | xgerman |
150 +------------------------+---------------------------+----------------------+
151 | vmware-nsx | Gary Kotton | garyk |
152 +------------------------+---------------------------+----------------------+
154 Existing Core Reviewers
155 -----------------------
157 Existing core reviewers have been reviewing code for a varying degree of
158 cycles. With the new plan of Lieutenants and ownership, it's fair to try to
159 understand how they fit into the new model. Existing core reviewers seem
160 to mostly focus in particular areas and are cognizant of their own strengths
161 and weaknesses. These members may not be experts in all areas, but know their
162 limits, and will not exceed those limits when reviewing changes outside their
163 area of expertise. The model is built on trust, and when that trust is broken,
164 responsibilities will be taken away.
166 Lieutenant Responsibilities
167 ---------------------------
169 In the hierarchy of Neutron responsibilities, Lieutenants are expected to
170 partake in the following additional activities compared to other core
173 * Ensuring feature requests for their areas have adequate testing and
174 documentation coverage.
175 * Gate triage and resolution. Lieutenants are expected to work to keep the
176 Neutron gate running smoothly by triaging issues, filing elastic recheck
177 queries, and closing gate bugs.
178 * Triaging bugs for the specific areas.
183 Given all of the above, Neutron has the following core reviewer teams with
184 responsibility over the areas of code listed below:
186 Neutron Core Reviewer Team
187 --------------------------
188 `Neutron core reviewers <https://review.openstack.org/#/admin/groups/38,members>`_ have
189 merge rights to the following git repositories:
191 * `openstack/neutron <https://git.openstack.org/cgit/openstack/neutron/>`_
192 * `openstack/python-neutronclient <https://git.openstack.org/cgit/openstack/python-neutronclient/>`_
194 Please note that as we adopt to the system above with core specialty in
195 particular areas, we expect this broad core team to shrink as people naturally
196 evolve into an area of specialization.
198 Neutron FWaaS Core Reviewer Team
199 --------------------------------
200 Neutron `FWaaS core reviewers <https://review.openstack.org/#/admin/groups/500,members>`_
201 have merge rights to the following git repositories:
203 * `openstack/neutron-fwaas <https://git.openstack.org/cgit/openstack/neutron-fwaas/>`_
205 Neutron LBaaS Core Reviewer Team
206 --------------------------------
207 Neutron `LBaaS core reviewers <https://review.openstack.org/#/admin/groups/501,members>`_
208 have merge rights to the following git repositories:
210 * `openstack/neutron-lbaas <https://git.openstack.org/cgit/openstack/neutron-lbaas/>`_
212 Neutron VPNaaS Core Reviewer Team
213 ---------------------------------
214 Neutron `VPNaaS core reviewers <https://review.openstack.org/#/admin/groups/502,members>`_
215 have merge rights to the following git repositories:
217 * `openstack/neutron-vpnaas <https://git.openstack.org/cgit/openstack/neutron-vpnaas/>`_
219 Neutron Core Reviewer Teams for Plugins and Drivers
220 ---------------------------------------------------
221 The plugin decomposition effort has led to having many drivers with code in
222 separate repositories with their own core reviewer teams. For each one of
223 these repositories in the following repository list, there is a core team
226 * `Neutron project team <http://governance.openstack.org/reference/projects/neutron.html>`_
228 These teams are also responsible for handling their own specs/RFEs/features if
229 they choose to use them. However, by choosing to be a part of the Neutron
230 project, they submit to oversight and veto by the Neutron PTL if any issues
233 Neutron Specs Core Reviewer Team
234 --------------------------------
235 Neutron `specs core reviewers <https://review.openstack.org/#/admin/groups/314,members>`_
236 have +2 rights to the following git repositories:
238 * `openstack/neutron-specs <https://git.openstack.org/cgit/openstack/neutron-specs/>`_
240 The Neutron specs core reviewer team is responsible for reviewing specs targeted to
241 all Neutron git repositories (Neutron + Advanced Services). It is worth noting that
242 specs reviewers have the following attributes which are potentially different than
245 * Broad understanding of cloud and networking technologies
246 * Broad understanding of core OpenStack projects and technologies
247 * An understanding of the effect approved specs have on the teams development
248 capacity for each cycle
250 Specs core reviewers may match core members of the above mentioned groups, but
251 the group can be extended to other individuals, if required.
256 The `drivers team <https://review.openstack.org/#/admin/groups/464,members>`_ is
257 the group of people who have full rights to the specs repo. This team, which matches
258 `Launchpad Neutron Drivers team <https://launchpad.net/~neutron-drivers>`_, is
259 instituted to ensure a consistent architectural vision for the Neutron project, and
260 to continue to disaggregate and share the responsibilities of the Neutron PTL.
261 The team is in charge of reviewing and commenting on
262 `RFEs <http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements>`_,
263 and working with specification contributors to provide guidance on the process
264 that govern contributions to the Neutron project as a whole. The team
265 `meets regularly <https://wiki.openstack.org/wiki/Meetings/NeutronDrivers>`_
266 to go over RFE's and discuss the project roadmap. Anyone is welcome to join
267 and/or read the meeting notes.
272 The `release team <https://review.openstack.org/#/admin/groups/150,members>`_ is
273 a group of people with some additional gerrit permissions primarily aimed at
274 allowing release management of Neutron sub-projects. These permissions include:
276 * Ability to push signed tags to sub-projects whose releases are managed by the
277 Neutron release team as opposed to the OpenStack release team.
278 * Ability to push merge commits for Neutron or other sub-projects.
279 * Ability to approve changes in all Neutron git repositories. This is required
280 as the team needs to be able to quickly unblock things if needed, especially
283 Code Merge Responsibilities
284 ===========================
286 While everyone is encouraged to review changes for these repositories, members
287 of the Neutron core reviewer group have the ability to +2/-2 and +A changes to
288 these repositories. This is an extra level of responsibility not to be taken
289 lightly. Correctly merging code requires not only understanding the code
290 itself, but also how the code affects things like documentation, testing, and
291 interactions with other projects. It also means you pay attention to release
292 milestones and understand if a patch you're merging is marked for the release,
293 especially critical during the feature freeze.
295 The bottom line here is merging code is a responsibility Neutron core reviewers
298 Adding or Removing Core Reviewers
299 ---------------------------------
301 A new Neutron core reviewer may be proposed at anytime on the openstack-dev
302 mailing list. Typically, the Lieutenant for a given area will propose a new
303 core reviewer for their specific area of coverage, though the Neutron PTL may
304 propose new core reviewers as well. The proposal is typically made after
305 discussions with existing core reviewers. Once a proposal has been made,
306 three existing Neutron core reviewers from the Lieutenant's area of focus must
307 respond to the email with a +1. If the member is being added by a Lieutenant
308 from an area of focus with less than three members, a simple majority will be
309 used to determine if the vote is successful. Another Neutron core reviewer
310 from the same area of focus can vote -1 to veto the proposed new core
311 reviewer. The PTL will mediate all disputes for core reviewer additions.
313 The PTL may remove a Neutron core reviewer at any time. Typically when a
314 member has decreased their involvement with the project through a drop in
315 reviews and participation in general project development, the PTL will propose
316 their removal and remove them. Please note there is no voting or vetoing of
317 core reviewer removal. Members who have previously been a core reviewer may be
318 fast-tracked back into a core reviewer role if their involvement picks back up
319 and the existing core reviewers support their re-instatement.
321 Neutron Core Reviewer Membership Expectations
322 ---------------------------------------------
324 Neutron core reviewers have the following expectations:
326 * Reasonable attendance at the weekly Neutron IRC meetings.
327 * Participation in Neutron discussions on the mailing list, as well as
328 in-channel in #openstack-neutron.
329 * Participation in Neutron related design summit sessions at the OpenStack
332 Please note in-person attendance at design summits, mid-cycles, and other code
333 sprints is not a requirement to be a Neutron core reviewer. The Neutron team
334 will do its best to facilitate virtual attendance at all events. Travel is not
335 to be taken lightly, and we realize the costs involved for those who partake
336 in attending these events.
338 In addition to the above, code reviews are the most important requirement of
339 Neutron core reviewers. Neutron follows the documented OpenStack `code review
340 guidelines <https://wiki.openstack.org/wiki/ReviewChecklist>`_. We encourage
341 all people to review Neutron patches, but core reviewers are required to
342 maintain a level of review numbers relatively close to other core reviewers.
343 There are no hard statistics around code review numbers, but in general we
344 use 30, 60, 90 and 180 day stats when examining review stats.
346 * `30 day review stats <http://stackalytics.com/report/contribution/neutron-group/30>`_
347 * `60 day review stats <http://stackalytics.com/report/contribution/neutron-group/60>`_
348 * `90 day review stats <http://stackalytics.com/report/contribution/neutron-group/90>`_
349 * `180 day review stats <http://stackalytics.com/report/contribution/neutron-group/180>`_
351 There are soft-touch items around being a Neutron core reviewer as well.
352 Gaining trust with the existing Neutron core reviewers is important. Being
353 able to work together with the existing Neutron core reviewer team is
354 critical as well. Being a Neutron core reviewer means spending a significant
355 amount of time with the existing Neutron core reviewers team on IRC, the
356 mailing list, at Summits, and in reviews. Ensuring you participate and engage
357 here is critical to becoming and remaining a core reviewer.
Code Review / openstack-build / neutron-build.git / blob