This document describes the structure of the Fuel team and how it is used to organize code review, design discussions, and overall technical decision making process in the Fuel project.
Code review is the primary tool for day to day interactions between Fuel contributors. Problems with code review process can be grouped into two buckets.
It is hard to get code reviewed and merged:
Quality of code review itself could be better:
Having well defined areas of ownership in Fuel components addreses most of these problems: from making it easier to identify the right reviewers for your code, to prioritizing code review work so that core reviewers can spend more attention on smaller number of commits.
Subject matter expert in certain Fuel area of code, which they regularly contribute to and review code of other contributors into this area. For example: network checker or Nailgun agent would have their own lists of maintainers.
List of maintainers for different parts of a Fuel git repository is provided in a MAINTAINERS file at the top level of that repository. A repository that contains multiple components may have multiple MAINTAINERS files in the component subdirectories.
Typical commit goes through the following code review stages:
Fuel PTL is elected twice a year following the same cycle and rules as other OpenStack projects: all committers to all Fuel projects (fuel-* and python-fuelclient) over the last year can vote and can self-nominate.
Fuel aggregates features provided by Fuel components. Components could be either Fuel driven (like Nailgun, Astute, UI) or generic in a sense that Fuel is not the only use case for such components (e.g. Keystone, potentially Neutron, Ironic, Glance, etc.). Component teams are independent but should interact with each other while working on features.
Core team of a component is responsible for code review in their component. It is totally up to a component team (not Fuel team as a whole) to decide whether they resolve review conflicts by consensus or they delegate their voices to a formal or inforaml component lead. It should be up to a component team how they share review responsibilites and how they make architecture and planning decisions.
Core reviewers are approved by consensus of existing core reviewers, following the same process as with other OpenStack projects. Core reviewers can voluntarily step down, or be removed by consensus of existing core reviewers. Separate core reviewers list is maintained for each Fuel git repository.
Maintainers are defined by the contents of the MAINTAINERS files in Fuel git repositories, following the standard code review process. Any contributor can propose an update of a MAINTAINERS file; a core reviewer can approve an update that has a +2 from another core reviewer; if the update adds new maintainers, it must also have +1 votes from all added maintainers.
Since components could be generic there must be two levels of design. By-component design specs describe component changes that are not necessarily related to Fuel and these specs are out of the scope of this policy. Fuel design specs describe Fuel features that usually require coordinated changes in multiple components. Each Fuel spec must be reviewed and approved (+2) by matter experts from at least the following backgrounds (even if respective section is empty):
It is up to the Fuel-specs core team to involve other SMEs to review a particular spec if specific expertise is required.
Many other OpenStack projects keep a flat team structure: one elected PTL, and a single list of core reviewers for the whole project. The advantage is a more simple and straightforward governance process. The disadvantages are described in the problem description.
The current policy was put in place for Mitaka, and updated for Newton.
N/A
Note
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode