From 69dfba91d0d8dbe82a5d4beb732be1fb9e350728 Mon Sep 17 00:00:00 2001 From: Guillaume Smet Date: Thu, 20 Jan 2022 17:43:39 +0100 Subject: [PATCH] Update COMMITTERS.adoc with current process --- COMMITTERS.adoc | 55 +++++++++++++++++++++++++------------------------ 1 file changed, 28 insertions(+), 27 deletions(-) diff --git a/COMMITTERS.adoc b/COMMITTERS.adoc index bfd6edef4d9b1..6b81aa126c7b5 100644 --- a/COMMITTERS.adoc +++ b/COMMITTERS.adoc @@ -27,8 +27,8 @@ 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 by a specific person, make it a named reviewer via GitHub's "Reviewers" UI -* If someone asked for a specific reviewer, better give some time for this person to review the PR. +* 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), @@ -37,23 +37,26 @@ While not absolute, here is some advice: 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. - The idea is to have proper semantic commits. +* 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) https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork[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 of important things to check in the future. -* Only merge pull requests that target main. - **Dealing with old branches is a separate process.** + 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 <> for more details. * Do NOT affect a PR to an old branch, see the <> for more details. Obviously, each situation is different so use your own judgement, @@ -70,7 +73,7 @@ There are a few things you can do to help us be on schedule: That means: + ** Your PR needs to be created, obviously. - ** It should be reviewed by someone familiar with this area. + ** 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. @@ -93,11 +96,13 @@ Quarkus depends on a lot of third party dependencies that we try to keep up to d We partially rely on Dependabot for https://github.com/quarkusio/quarkus/blob/main/.github/dependabot.yml[a curated list of dependencies]. Some dependencies are critical for Quarkus and quite complex. -Good examples would be Vert.x or Hibernate ORM. +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]] == Backward Compatibility Quarkus evolves very fast and we decided we could break backward compatibility as long as: @@ -107,9 +112,12 @@ Quarkus evolves very fast and we decided we could break backward compatibility a 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 on the `quarkus-dev` mailing list +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`. @@ -172,22 +180,15 @@ GitHub won't detect issues properly if you do something like == Affecting Labels and Milestones Affecting labels and milestones is very important in our process. +The Quarkus Bot does it in most cases. -Before each release, we check that we don't have any -closed issues that don't have either a milestone affected or -some of the "excluding" labels. - -Thus: +In some cases, you might have to add some manually though: -* If you close a pull request because the committers have decided to not merge it, - please add the appropriate `triage/` label: `triage/invalid`, `triage/out-of-date`, - `triage/wontfix` are usually in order. -* If you close an issue because it has been fixed, either add the milestone - if you can find it easily or use the `triage/out-of-date` if you can't. -* If you close an issue for any other reason, one of the aforementioned `triage/` labels - is probably adequate. +* 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. + 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]] == Backporting Process @@ -195,7 +196,7 @@ Thus: 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. `1.7.0.Final`), we create a release branch (e.g. `1.7`) to host +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 @@ -229,11 +230,11 @@ when we prepare the next bugfix release. == Good First Issues -We need to find the right balance between fixing the issue right away +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 the issue is appropriate, -affecting it the `good first issue` label for some time might be a good thing. +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 :).