COMMITTERS.adoc

Information for Quarkus Committers

This document contains useful information for Quarkus committers.

Note	It is a work in progress, so if you think information is missing/unclear/inadequate, please reach out to us on the quarkus-dev mailing-list.

This document has a lot of information. It is not a set of strict rules, it is here to guide you. If you forget to do something, miss something, don’t worry, it happens.

Do your best and that will already be a lot :).

Merging Pull Requests

The first thing is that, while being a committer, you can’t really commit directly to the main repository: you need at least one review by your peers.

Thus the need for a pull request.

So you are more like a merger than a committer and you might merge more PRs from others than your own work.

While not absolute, here is some advice:

• If you really want a review from a specific person, make it a named reviewer via GitHub’s "Reviewers" feature

• If someone asked for a specific reviewer, better give some time to this person to review the PR. If not reviewed in a reasonable amount of time, better ping them again to have some information or ask the original author if we should go ahead.

• If in doubt (on a specific part or because you’re not comfortable reviewing documentation or any other reason), ask for help.

• Except if it’s a total no-brainer (typically a typo fix), let the PR bake a few hours so some other people can have a look if interested. If the PR is very large or is a new extension, better let it bake for a few days.

• We do merge commits so please ask the author to properly squash the commits before merging (when it makes sense). The idea is to have proper semantic commits. Several commits is not a problem as long as they have a proper semantic. If the author is not familiar with Git or not available, you can also (carefully) do it for them as long as you both agreed on it.

• Make sure the commit comments are meaningful.

• As a new committer, you can start by giving your approval and not merging and see how things evolve. This should give you some hints on important things to check in the future.

• Only merge pull requests that target main. Dealing with older branches is a separate process.

• If you are sure a PR should go in and is just waiting for CI, just use the triage/waiting-for-ci label. It is a good hint for other committers.

• If you think a pull request is an essential part of a given milestone (and can realistically be a part of it), you should affect this milestone to it so that we can be sure it stays on the radar. Otherwise, better not do it and let the Quarkus bot do it for you.

• If you think a pull request is worth mentioning in the release notes and/or the announcement blog post, add the release/noteworthy-feature label.

• If you think a pull request introduces some breaking changes, add the release/breaking-change label, see Backward Compatibility for more details.

• Do NOT affect a PR to an old branch, see the backporting process for more details.

Obviously, each situation is different so use your own judgement, and if in doubt, just ask for advice, the other committers are here to help.

Release Schedule

The release schedule is posted here: https://github.com/quarkusio/quarkus/wiki/Release-Planning .

There are a few things you can do to help us be on schedule:

• Anything that goes in a release should have been merged the day before the release. That means:

  • Your PR needs to be created, obviously.

  • It should have been reviewed by someone familiar with this area.

  • You have to take this feedback into account.

  • And once approved, the PR can be merged.

  • Also, keep in mind that we have a 3 hours CI cycle and CI needs to be green before any inclusion.

    In short, posting a large PR the day before the release won’t work.

• In the case of a significant change, the release considered for inclusion shouldn’t be the .Final but the .CR1.. Thus, your PR has to be merged the day before the release of .CR1.

• If, for some reason, a PR really needs to be part of a given release, better coordinate with the release manager and the potential reviewers so that everyone is aware something big is coming. Potential reviewers might also have their own agenda and work to be included in the release, thus not always having the cycles to review last minute.

Dependency Upgrades

Quarkus depends on a lot of third party dependencies that we try to keep up to date.

We partially rely on Dependabot for a curated list of dependencies.

Some dependencies are critical for Quarkus and quite complex. Good examples would be Netty, Vert.x or Hibernate ORM.

It is good practice to update these core dependencies at the beginning of a given release cycle to let them time to bake in the main branch before being released. And, in any case, we should avoid upgrading these dependencies after the CR1 when we can.

Backward Compatibility

Quarkus evolves very fast and we decided we could break backward compatibility as long as:

• It is worth it.

• We try to support the previous behavior for a while - if it doesn’t have a prohibitive cost, be it in terms of development time or added complexity.

Usually, it is a good idea to have the opinion of people involved in the development of this area. And for widely used extensions or core changes, sending an email to the quarkus-dev mailing list should be considered.

When deprecating things, make sure to keep the deprecations for 12 months, except you have a very good reason not doing so (and in this case, let’s discuss it on quarkus-dev).

Breaking changes should be marked with the release/breaking-change label and, if they need to be included in the release notes and/or announcement blog post, they should also be labelled with release/noteworthy-feature.

They must be documented in the migration guide of the appropriate version: https://github.com/quarkusio/quarkus/wiki/Migration-Guides.

Pull Request Title

The title should be in English, should not contain an issue number. It should also not contain ellipsis.

If your commit message was too long and GitHub automatically cut the title, it is helpful if you can take the time to move the cut part where it belongs to have a full title.

Titles are included in the Release notes so they are important.

A good title would look like: Fix off by one issue in Quartz extension or Introduce Hibernate Reactive extension.

A bad title would look like: fix(#444).

Issues Fixed

When a PR fixes some issues, it’s good practice to add it in the description (and not in the title!).

One issue per line with something like:

* Fix #444
* Fix #555

Given GitHub automatically extracts the commit information to fill in the PR fields, just make your commit comment look like:

Fix off by one issue in Quartz extension

* Fix #444
* Fix #555

Tip	GitHub supports a variety of keywords here: fix, fixes, fixed, resolve, resolves, resolved, close, closes, closed all do the same thing.

Warning

GitHub won’t detect issues properly if you do something like Fix #444 #555.

Affecting Labels and Milestones

Affecting labels and milestones is very important in our process. The Quarkus Bot does it in most cases.

In some cases, you might have to add some manually though:

• If you close an issue that has not been closed automatically, either affect a milestone if it has been fixed or one of the triage/invalid, triage/out-of-date, triage/wontfix labels if not.

• Some issues are created as kind/bug but are more support questions: in this case, remove the kind/bug label and add the kind/question label or even better redirect them to the Discussions section.

Backporting Process

When we release a new version of Quarkus, we usually do a bugfix release a couple of weeks after.

Every time we do a major release (e.g. 2.7.0.Final), we create a release branch (e.g. 2.7) to host the commits for these bugfix releases.

All the pull requests are merged in the main branch so they are applied to the new feature release of Quarkus. They won’t be integrated in the previous version branch.

Some pull requests however may qualify for being backported to this bugfix branch.

Good examples of that might be:

• bugfixes

• documentation fixes

• usability fixes

Obviously, the barrier is higher for large pull requests as they might be more risky to backport. But sometimes, we just have to backport them anyway.

If you think your pull request or the pull request you are reviewing, might be a good backport candidate, please add the triage/backport? label.

The question mark is important: it is not automatic and we carefully review each pull request before backporting.

Thus, if not entirely clear, don’t hesitate to add a comment to the pull request when adding the label.

And don’t be surprised if we come to you with some questions about it when we prepare the next bugfix release.

Good First Issues

We need to find the right balance between fixing the issues right away and trying to onboard new contributors.

It’s not always easy to find one, but if you think an issue is appropriate, affecting the good first issue label to it for some time might be a good thing.

Obviously, critical bugs are not good candidates :).

I Did Something Wrong, What Should I Do?

Take a deep breath and don’t worry, it happens.

Just ping @quarkusio/committerhelp on GitHub or @committerhelp on Zulip and we will find a solution.