Do you ❤️ Trino? Give us a 🌟 on GitHub

Development

Roles

Overview #

Everyone is encouraged to participate in the Trino project. Anyone can influence the project by simply being involved in the discussions about new features, the roadmap, architecture, and problems they are facing. The various roles described here do not carry more weight in these discussions, and instead we try to always work towards consensus. The Trino project has a strong vision and development philosophy that helps to guide discussions and allows us to reach consensus. When we can’t come to consensus, we work to figure out what we agree on, and what we don’t. Then we move forward by building what we agree on, which helps everyone better understand the parts we don’t agree on, and hopefully builds empathy at the same time.

The following describes the expectations and duties of the various roles.

Participants #

This is the most important role. Very simply put, participants are those who show up and join in discussions about the project. Users, developers, and administrators can all be participants, as can literally anyone who has the time, energy, and passion to become involved. Participants suggest improvements and new features. They report bugs, regressions, performance issues, and so on. They work to make Trino better for everyone.

Expectations and duties:

  • Be involved in discussions about features, roadmaps, architecture, and long-term plans.
  • Help other users on the mailing list, on GitHub issues, and on Slack.
  • Propose and discuss new features and improvements.
  • Help raise the project’s quality.
  • Let everyone else know what isn’t working or is confusing.
  • Report bugs and performance regressions.
  • Suggest improvements to infrastructure and testing.
  • Recommend improvements to documentation and the website.
  • Understand that although English is the language of this project, English is not the first language of many participants. Assume positive intent from others and realize that negative sounding comments are often unintentional due to language barriers.

Contributors #

A contributor submits changes to Trino. The full contribution process is described here.

Expectations and duties:

  • Be empathetic to the reviewers. Reviewing a change can be hard work and time-consuming.
  • Keep commits small when possible and provide reasoning and context when submitting changes. Reviews go smoother if you make the reviewer’s job easier.
  • Be responsive when changes are requested by the reviewer. It is easier to re-review the modified changes if they are completed shortly after original review.
  • Ask for clarification if you are confused by a suggested change.
  • Speak up if your contribution appears to be stuck.
  • Read the project vision and development philosophy.
  • Follow the style guidelines and more importantly, follow the Trino coding conventions by matching your code to the existing code. Keep in mind the Trino development philosophy is to have all code appear as if it were written by a single person.
  • Sign the contributor license agreement (CLA).

You can view all contributors on GitHub.

Reviewers #

A reviewer reads a proposed change to Trino, and assesses how well the change aligns with the Trino vision and guidelines. This includes everything from high level project vision to low level code style. Everyone is invited and encouraged to review others’ contributions – you don’t need to be a maintainer for that.

Expectations and duties:

  • Be empathetic to contributors. They may have put a lot of effort into the proposed change and may not be familiar with the codebase, the process, or the history of the project.
  • Be responsive to questions.
  • Re-review after suggested changes have been applied.
  • Be clear about which changes are only suggestions, and which changes are necessary.
  • Let the contributor know what is going on, so reviews don’t appear to be stuck.
  • Raise a discussion when a change does not seem to align with the vision or development philosophy.
  • Point out deviations from the code conventions and style guidelines.
  • Ask for help reviewing areas you don’t understand.

Maintainers #

In Trino, maintainer is an active role. A maintainer is responsible for merging code only after ensuring it has been reviewed thoroughly and aligns with the Trino vision and guidelines. In addition to merging code, a maintainer actively participates in discussions and reviews. Being a maintainer does not grant additional rights in the project to make changes, set direction, or anything else that does not align with the direction of the project. Instead, a maintainer is expected to bring these to the project participants as needed to gain consensus. The maintainer role is for an individual, so if a maintainer changes employers, the role is retained. However, if a maintainer is no longer actively involved in the project, their maintainer status will be reviewed.

Expectations and duties:

  • Be an active reviewer and participant.
  • Know which changes are likely to be controversial, and work to resolve the controversy as early as possible.
  • Know when a change needs more reviewers involved.
  • Add the language lead to reviews when appropriate.
  • Ensure the review of a proposed change is thorough.
  • Point out when a contribution appears to be stuck.
  • Assist with the authoring of release notes.
  • Follow the CLA and IP policies.

An Apache Hive committer did an excellent write up on their process and much of this aligns with our philosophy on maintainers. Read about it.

Trino maintainers typically focus on the core trino repository, but many also work across other projects in the trinodb organization and upstream projects such as airlift, and assist with the trinodb subprojects.

The following community members are Trino maintainers:

Full name
dain Dain Sundstrom
ebyhr Yuya Ebihara
electrum David Phillips
findepi Piotr Findeisen
hashhar Ashhar Hasan
kasiafi Kasia Findeisen
kokosing Grzegorz Kokosiński
losipiuk Łukasz Osipiuk
martint Martin Traverso
mosabua Manfred Moser
pettyjamesm James Petty
Praveen2112 Praveen Krishna
raunaqmorarka Raunaq Morarka
sopel39 Karol Sobczak
wendigo Mateusz Gajewski

Path to becoming a maintainer #

  1. Read: Understand the project values and scope, the development philosophy and guidelines, and the change process. These contain necessary background information to be successful in Trino.
  2. Contribute: This helps you learn the codebase, and understand the development process. Start with something small to become familiar with the process.
  3. Review: Once you become familiar with a part of Trino, start reviewing proposed changes to that part. A maintainer does an additional final review, and this helps you understand what you are missing in your reviews. At some point, your first pass reviews will not require additional changes during the final review.
  4. Maintainer: The next step is to demonstrate an understanding of what you know and don’t know. It is common for changes to require reviews from multiple people, since no one person is familiar with all of Trino. We are also looking for an understanding of the project values and technical vision. Being a maintainer means reviewing and merging code in your areas of expertise from all contributors. The maintainer role is retained while being active in the project.

Subproject maintainers #

A subproject maintainer on the Trino project is a maintainer with limited scope in terms of access to specific repositories within the trinodb GitHub organization. The scope is also limited in terms of the used technologies.

Subproject maintainers only have merge access on a specific subproject repository. Subproject repositories cover a subset of the overall scope of the Trino project. They are often associated to a specific aspect of running the project or a technology stack and integration for Trino.

Examples for subproject repositories are the trino.io website source or the grafana-trino repository for the Trino Grafana data source plugin. Other potential subprojects are trino-python-client, trino-go-client, and charts.

Expectations and duties:

The expectations and duties of a subproject maintainer are identical to those of a maintainer, but limited to the subproject repository and the related technologies.

Subprojects #

The following subproject repositories and subproject maintainers are configured:

aws-proxy - Proxy for AWS S3

charts - Helm charts for Trino

grafana-trino - Grafana data source plugin for Trino

trino.io - Trino website

trino-gateway - Trino Gateway load balancer and router

trino-go-client - Trino client fo Go

trino-js-client - Trino client for Javascript

Language lead #

The language lead is the maintainer specifically responsible for maintaining the SQL language implementation in Trino. Trino attempts to adhere to the ANSI SQL specification and related extensions and conventions as closely as possible. Because SQL is the primary interface for Trino users, the language lead serves as the sole decision maker regarding SQL language decisions. The primary objective for this role is to maintain compatibility between versions and ensure adherence to the SQL standard. All pull requests making changes or additions to Trino SQL syntax, types, and function library must have the syntax-needs-review label and be reviewed by the language lead.

Martin Traverso martint is the language lead.

File system lead #

The file system lead is the maintainer specifically responsible for maintaining the TrinoFileSystem APIs for accessing files and file systems, typically used in the object storage connectors.

The TrinoFileSystem APIs are carefully designed to contain only the operations needed by Trino, and with a goal of each operation being simple to understand, fully documented, and thoroughly tested. These APIs replace the legacy Hadoop FileSystem APIs. With the new APIs, the project improves developer productivity, because you can rely on the documented behavior and be confident this is verified by tests. Additionally, the clarity of the requirements for the APIs empowers developers to add support for additional file systems.

To maintain this simplicity, the APIs are only changed and expanded in a very conservative and careful manner. Any such changes of the API and its behavior musted be reviewed and approved by the file system lead.

David Phillips electrum is the file system lead.

Benevolent dictators for life #

Common among other open source projects, the role of benevolent dictator for life (BDFL) empowers particularly esteemed maintainers to act as the ultimate authority for technical decisions. In circumstances where the maintainers are divided or uncertain about how to proceed on a given issue, final say will defer to the benevolent dictators.

Expectations and duties:

  • Lead the maintainer team, including upholding policies and appointing new maintainers.
  • Resolve disputes and provide rulings on technical matters to move the project forward.
  • Listen and answer to the community. The benevolent dictators are benevolent, and their goal is to act in the best interests of Trino, its contributors, and its users.

Dain Sundstrom dain, David Phillips electrum, and Martin Traverso martint are the BDFLs.

Trino Software Foundation #

The Trino Software Foundation is the governing authority of the entire Trino project. Though it does not get involved in day-to-day discussions or technical decisions, it maintains oversight of the project and intellectual property. You can read more about the Trino Software Foundation here.

Table of contents