From e7aaf12299076c755c51d49a4ef463ab93ea772c Mon Sep 17 00:00:00 2001 From: Benoit Marty Date: Wed, 13 Apr 2022 15:34:24 +0200 Subject: [PATCH 1/3] Add a paragraph about the target branch, and a word about `develop` branch content. --- docs/pull_request.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/pull_request.md b/docs/pull_request.md index b4dd0bd209..1aa034c6ce 100644 --- a/docs/pull_request.md +++ b/docs/pull_request.md @@ -30,6 +30,17 @@ In any case, it is better to explicitly declare in the description why the PR is Also, draft PR should not stay indefinitely in this state. It may be removed if it is the case and the submitter does not update it after a few days. +##### Base branch + +The `develop` branch is generally the base branch for every PRs. + +Exceptions can occur: + +- if a feature implementation is split into multiple PRs. We can have a chain of PRs in this case. PR can be merged one by one on develop, and GitHub change the target branch to `develop` for the next PR automatically. +- we want to merge a PR from the community, but there is still work to do, and the PR is not updated by the submitter. In this case, we can create a new branch, push it, and change the target branch of the PR to this new branch. The PR can then be merged, and we can add more commits to fix the issues. After that a new PR can be created with `develop` as a target branch. + +**Important notice:** Releases are created from the `develop` branch. So `develop` branch should always contain a "releasable" source code. So when a feature is being implemented with several PRs, it has to be disabled by default, until the feature is fully implemented. A last PR to enable the feature can then be created. + ##### PR Review Assignment We use automatic assignment for PR reviews. A PR is automatically routed by GitHub to a team member using the round robin algorithm. The process is the following: From 773b9b7764364acaf889e93a31ec2765c0fd73d3 Mon Sep 17 00:00:00 2001 From: Benoit Marty Date: Wed, 13 Apr 2022 15:42:36 +0200 Subject: [PATCH 2/3] Add a notice about database migration --- docs/pull_request.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/pull_request.md b/docs/pull_request.md index 1aa034c6ce..e5c3e910f4 100644 --- a/docs/pull_request.md +++ b/docs/pull_request.md @@ -39,7 +39,9 @@ Exceptions can occur: - if a feature implementation is split into multiple PRs. We can have a chain of PRs in this case. PR can be merged one by one on develop, and GitHub change the target branch to `develop` for the next PR automatically. - we want to merge a PR from the community, but there is still work to do, and the PR is not updated by the submitter. In this case, we can create a new branch, push it, and change the target branch of the PR to this new branch. The PR can then be merged, and we can add more commits to fix the issues. After that a new PR can be created with `develop` as a target branch. -**Important notice:** Releases are created from the `develop` branch. So `develop` branch should always contain a "releasable" source code. So when a feature is being implemented with several PRs, it has to be disabled by default, until the feature is fully implemented. A last PR to enable the feature can then be created. +**Important notice 1:** Releases are created from the `develop` branch. So `develop` branch should always contain a "releasable" source code. So when a feature is being implemented with several PRs, it has to be disabled by default, until the feature is fully implemented. A last PR to enable the feature can then be created. + +**Important notice 2:** Database migration: some developers and some people from the community are using the nightly build from `develop`. Multiple database migrations should be properly handled for them. This is OK to have multiple migrations between 2 releases, this is not OK to add steps to the pending database migration on `develop`. So for instance `develop` users will migrate from version 11 to version 12, then 13, then 14, and `main` users will do all those steps after they get the app upgrade. ##### PR Review Assignment From 3faf0a238ce29c90f6866128cb97a1158089fa7d Mon Sep 17 00:00:00 2001 From: Benoit Marty Date: Wed, 4 May 2022 17:57:47 +0200 Subject: [PATCH 3/3] Update after PR reviews --- docs/pull_request.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/pull_request.md b/docs/pull_request.md index e5c3e910f4..9bfdd82d4d 100644 --- a/docs/pull_request.md +++ b/docs/pull_request.md @@ -37,9 +37,9 @@ The `develop` branch is generally the base branch for every PRs. Exceptions can occur: - if a feature implementation is split into multiple PRs. We can have a chain of PRs in this case. PR can be merged one by one on develop, and GitHub change the target branch to `develop` for the next PR automatically. -- we want to merge a PR from the community, but there is still work to do, and the PR is not updated by the submitter. In this case, we can create a new branch, push it, and change the target branch of the PR to this new branch. The PR can then be merged, and we can add more commits to fix the issues. After that a new PR can be created with `develop` as a target branch. +- we want to merge a PR from the community, but there is still work to do, and the PR is not updated by the submitter. First, we can kindly ask the submitter if they will update their PR, by commenting it. If there is no answer after a few days (including a week-end), we can create a new branch, push it, and change the target branch of the PR to this new branch. The PR can then be merged, and we can add more commits to fix the issues. After that a new PR can be created with `develop` as a target branch. -**Important notice 1:** Releases are created from the `develop` branch. So `develop` branch should always contain a "releasable" source code. So when a feature is being implemented with several PRs, it has to be disabled by default, until the feature is fully implemented. A last PR to enable the feature can then be created. +**Important notice 1:** Releases are created from the `develop` branch. So `develop` branch should always contain a "releasable" source code. So when a feature is being implemented with several PRs, it has to be disabled by default (using a feature flag for instance), until the feature is fully implemented. A last PR to enable the feature can then be created. **Important notice 2:** Database migration: some developers and some people from the community are using the nightly build from `develop`. Multiple database migrations should be properly handled for them. This is OK to have multiple migrations between 2 releases, this is not OK to add steps to the pending database migration on `develop`. So for instance `develop` users will migrate from version 11 to version 12, then 13, then 14, and `main` users will do all those steps after they get the app upgrade.