264 lines
12 KiB
ReStructuredText
264 lines
12 KiB
ReStructuredText
:title: OpenDev Project
|
|
|
|
.. _infra-project:
|
|
|
|
OpenDev Project
|
|
###############
|
|
|
|
OpenDev is an evolution of the OpenStack Infrastructure project. The
|
|
goal is to make OpenStack's proven software development tools available
|
|
for projects outside of OpenStack. We believe that Free Software needs
|
|
Free tools and OpenDev provides one such set that has been proven to
|
|
work at large and small scales of development.
|
|
|
|
The OpenDev team is an open meritocracy that welcomes new members. We
|
|
follow OpenStack's `Four Opens <https://www.openstack.org/four-opens/>`_.
|
|
|
|
Scope
|
|
=====
|
|
|
|
OpenDev now covers many of the original OpenStack Infrastructure systems,
|
|
but not all. The goal is to run any service that has generic applicability
|
|
for open and collaborative software development in OpenDev. OpenStack and
|
|
other project specific tooling would be managed by those projects outside
|
|
of OpenDev.
|
|
|
|
In particular OpenDev covers the operations and development of code
|
|
management systems and collaboration tools. Git repository management, code
|
|
review, continuous integration, etherpads, mailing lists, and more are all
|
|
within the scope of OpenDev. All of the software we run is open source, and
|
|
openly operated through configuration files stored in git.
|
|
|
|
Contributing
|
|
============
|
|
|
|
.. note::
|
|
|
|
Until we complete the transition from OpenStack Infra to OpenDev some
|
|
communication platforms will remain under "OpenStack". Expect
|
|
this list to get smaller over time.
|
|
|
|
We welcome contributions from new contributors. Reading this
|
|
documentation is the first step. You should also join our `mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra>`_.
|
|
|
|
We are most active on IRC, so please join the **#opendev**
|
|
channel on OFTC.
|
|
|
|
Feel free to attend our `weekly IRC meeting
|
|
<https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting>`_
|
|
on Tuesdays at 19:00 UTC in #opendev-meeting on OFTC.
|
|
|
|
To read about how our systems are managed and how to view or edit
|
|
those configurations, see :ref:`sysadmin`.
|
|
|
|
We also have a collection of `OpenStack Project Infrastructure Publications
|
|
<http://docs.openstack.org/infra/publications/>`_ where we host slides for
|
|
presentations team members have given about the infrastructure.
|
|
|
|
And if you have any questions, please ask.
|
|
|
|
Bugs
|
|
====
|
|
|
|
The OpenDev project maintains a bug list at:
|
|
https://storyboard.openstack.org/#!/project_group/55
|
|
|
|
Both defects and new features are tracked in the bug system. A number
|
|
of tags are used to indicate relevance to a particular subsystem.
|
|
There is also a low-hanging-fruit tag associated with bugs that should
|
|
provide a gentle introduction to working on the OpenDev project
|
|
without needing too much in-depth knowledge or access.
|
|
|
|
Priority Efforts
|
|
================
|
|
|
|
The OpenDev project designates a small number of efforts
|
|
underway at any time as priority efforts. These are areas where the
|
|
project has decided to focus resources to achieve major initiatives.
|
|
These help reviewers prioritize their review workload and help to
|
|
ensure the project accomplishes important tasks. Priority efforts are
|
|
a great way to get involved in the project as they will generally
|
|
provide the most interaction with experienced contributors.
|
|
|
|
Priority efforts are documented in the infra-specs repo. Each
|
|
priority effort has one entry in infra-specs, though that may link to
|
|
multiple smaller specifications for individual units of work if the
|
|
effort is sufficiently large. Each priority effort also has a single
|
|
person designated as the driver of that effort. That person is
|
|
responsible for ensuring that anything blocking progress of the effort
|
|
is discussed at team meetings and may be a good point of contact for
|
|
someone who wants to get involved.
|
|
|
|
Changes not related to priority efforts will be reviewed by the core
|
|
review team as time permits. This may mean that they spend
|
|
considerable time in review, but they will be reviewed eventually. If
|
|
a change is urgent, you might consider contacting someone in
|
|
#opendev on OFTC.
|
|
|
|
Governance
|
|
==========
|
|
|
|
The OpenDev project is governed by two entities. The first is the
|
|
Service Coordinator. They coordinate work of contributors and act as
|
|
a tie breaker when clear consensus isn't found. The Service Coordinator is
|
|
responsible for managing spec reviews and core team membership (details
|
|
below). This role is essentially the same as the old Infra PTL role.
|
|
|
|
The Service Coordinator is elected every 6 months. The nominee pool and
|
|
electorate are individuals that have contributed changes to OpenDev git
|
|
repositories in the last 12 months.
|
|
|
|
The second is an Advisory Board made up of representatives from OpenDev's
|
|
user base of projects and organizations that contribute compute resources.
|
|
This Advisory Board provides a formal location for those key
|
|
stakeholders to express their needs to the OpenDev project.
|
|
This creates a clear contact point for feedback on priorities and direction.
|
|
Their input will help ensure that the OpenDev project is a good steward of
|
|
the resources provided to it and that user needs are being addressed.
|
|
|
|
Contributing orgs and user projects are not required to join the Advisory
|
|
Board, but are encouraged to do so. Individuals on the board would be
|
|
selected by their own constituency as that constituency feels is
|
|
appropriate.
|
|
|
|
The Advisory Board will also serve as a point of contact for the OpenDev
|
|
project when making changes that may be disruptive. The intent is to create
|
|
bidirectional communication between OpenDev and its constituent
|
|
organizations.
|
|
|
|
Teams
|
|
-----
|
|
|
|
The OpenDev project is open, meaning anyone may join and begin
|
|
contributing with no formal process. As an individual's contributions
|
|
and involvement grow, there are more formal roles. These roles are
|
|
designed to empower groups of people to get work done in their area of
|
|
expertise and interest, as well as supply a strong sense of direction
|
|
for the OpenDev project as a whole. Everyone participating in
|
|
the project is encouraged to expand their own knowledge while helping
|
|
to support and mentor others as they progress.
|
|
|
|
Core Teams
|
|
The OpenDev project is composed of a large number of
|
|
subprojects. Every source code repository has its own core team
|
|
which is responsible for maintenance of that subproject, with some
|
|
groups of repositories sharing a core team. These core teams are
|
|
empowered to approve changes that reflect the currently understood
|
|
project direction. Changes in project direction or major new
|
|
initiatives must be approved by the OpenDev council.
|
|
|
|
Any existing core team member may nominate someone for addition to
|
|
that core team by private communication with the OpenDev Service
|
|
Coordinator. The Service Coordinator will consider the opinions of the
|
|
existing core team members and the review history of the person in
|
|
question, but final determination of core team membership (additions and
|
|
removals) rests with the Service Coordinator. This process is private to
|
|
enable honest evaluations in a safe environment.
|
|
|
|
OpenDev Core Team
|
|
Individuals who show an interest in a wide range of areas of the
|
|
OpenDev project may be asked to join the infra-core team. To
|
|
provide a baseline level of support to all of our subprojects and to
|
|
ensure that important efforts may move forward, this team has
|
|
approval rights in all OpenDev repositories. Members of this
|
|
team may not be experts in all areas, but know their limits, and
|
|
will not exceed those limits when reviewing changes outside of their
|
|
area of expertise.
|
|
|
|
They are expected to have a wide general knowledge of what is going
|
|
on in the OpenDev project and to help guide overall project
|
|
direction. To that end, they are able to veto specs proposed to the
|
|
OpenDev council.
|
|
|
|
OpenDev Council
|
|
The OpenDev council is the technical design body for the
|
|
Opendev project. While individuals and groups are empowered
|
|
to execute the designs from the council, major technical designs are
|
|
agreed upon as a group to ensure that our large set of projects are
|
|
all working together to the same end. The council need not delve
|
|
too deeply into technical detail -- just enough so that development
|
|
efforts may happen in parallel and work toward a common goal.
|
|
|
|
All members of any OpenDev project core team have a seat on
|
|
the Council. The Council is responsible for approving changes in
|
|
project direction, major new initiatives, setting priority efforts,
|
|
and addition or removal of projects.
|
|
|
|
Any such changes should be proposed to the infra-specs repository.
|
|
Anyone is welcome to review specs and they are expected to evolve
|
|
during the review process. When a change to infra-specs is ready
|
|
for final approval, the author will add the change to the infra team
|
|
meeting agenda so that the entire team is notified that the spec is
|
|
ready. Members of the council will vote by leaving reviews on the
|
|
spec to approve or reject the change. The determination will be
|
|
based on a majority vote, with members of the infra-core team able
|
|
to veto, and in the case of a tie, the Service Coordinator will cast
|
|
the deciding vote. The Service Coordinator will execute the workflow
|
|
action on the change after the vote.
|
|
|
|
Specs are living documents, and once approved, should be maintained
|
|
for the duration of the effort they describe. Substantial changes
|
|
in direction should go through the same process described above.
|
|
The Service Coordinator may chose to approve insubstantial changes
|
|
without the formal council voting process.
|
|
|
|
OpenDev Root Team
|
|
Core membership enables one to approve changes within our code
|
|
repositories. Because the OpenDev team operates
|
|
production servers there is another sub-group of the OpenDev
|
|
team that has root access to all servers. Root membership is
|
|
handled in the same way as core membership. Root members must also
|
|
be infra-core members, but infra-core members may not necessarily be
|
|
root members. This is because primary system administration is
|
|
performed through code review, so anyone able to log into a machine
|
|
to execute commands must be able to approve those same commands in
|
|
configuration management; otherwise it would be easier for a person
|
|
to bypass configuration management than use it in the intended
|
|
fashion.
|
|
|
|
Root access is generally only necessary to launch new servers,
|
|
perform low-level maintenance, manage DNS, or fix problems. In
|
|
general it is not needed for day-to-day system administration and
|
|
configuration which is done through automated config management tools
|
|
(where anyone may propose changes). Therefore it is generally
|
|
reserved for people who are well versed in OpenDev operations and can
|
|
commit to spending a significant amount of time troubleshooting on servers.
|
|
|
|
Some individuals may need root access to individual servers; in
|
|
these cases the infra-core group may grant root access on a limited
|
|
basis.
|
|
|
|
Review Criteria
|
|
===============
|
|
|
|
We review each others changes before they are merged. This helps us
|
|
improve the quality of the code we produce as well as ensure that we
|
|
are working together as a team. Generally we expect at least two
|
|
members of the core review team to approve a change before it is
|
|
merged, but we are flexible in this requirement -- typo fixes, or
|
|
other simple changes may be approved with less formality.
|
|
|
|
The primary purpose of change review is to catch substantial errors
|
|
before they are merged. In order to keep this process useful and
|
|
avoid frustration for both authors and reviewers, please do not leave
|
|
negative reviews for insubstantial faults or potential improvements.
|
|
The purpose is not to make someone else's code match your vision of
|
|
perfection, but to enable all of us to work together on a project.
|
|
|
|
Please use discretion when deciding what is important enough for
|
|
someone to spend the time to rework and for you to spend the time
|
|
re-reviewing. Sometimes minor things are important, such as
|
|
consistent use of hyphens versus underscores in a configuration
|
|
language. Sometimes they are not, such as whitespace in
|
|
documentation.
|
|
|
|
If you would like to mention minor improvements such as this, feel
|
|
free to do so, but please do not leave a negative score on the review.
|
|
If you mention them along with other more substantial criticisms,
|
|
please note them in a review, for example, with "(nit)" or "(not a
|
|
-1)" or "you may want to fix this if you are updating the patch
|
|
anyway".
|
|
|
|
Please also see the section in the Infrastructure Manual on `peer review
|
|
<https://docs.opendev.org/opendev/infra-manual/latest/developers.html#peer-review>`_.
|