Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
105 changes: 28 additions & 77 deletions Developer-guide/Backport-Guidelines.md
Original file line number Diff line number Diff line change
@@ -1,87 +1,38 @@
Bugs often get fixed in master before release branches. When a bug is
fixed in the master branch, it might be desirable or necessary in a
stable branch. To put the fix in the stable branch we need to backport the
fix to the stable branch.
In GlusterFS project, as a policy, any new change, bug fix, etc., are to be
fixed in 'master' branch before release branches. When a bug is fixed in
the master branch, it might be desirable or necessary in release branch.

Anyone in the community can suggest a backport. If you are interested to
suggest a backport, please check the [Backport
Wishlist](./Backport-Wishlist.md).
This page describes the policy GlusterFS has regarding the backports. As
a user, or contributor, being aware of this policy would help you to
understand how to request for backport from community.

This page describes the steps needed to backport simple changes. Changes
that do not apply cleanly will need some manual modifications and using
`git cherry-pick` may not always be the easiest solution.
## Policy

## via Git command-line
1. Git clone the GlusterFS code
* No feature from master would be backported to the release branch
* CVE ie., security vulnerability [(listed on the CVE database)](https://cve.mitre.org/cve/search_cve_list.html)
reported in the existing releases would be backported, after getting fixed
in master branch.
* Only topics which bring about data loss or, unavailability would be
backported to the release.
* For any other issues, the project recommends that the installation be
upgraded to a newer release where the specific bug has been addressed.
- Gluster provides 'rolling' upgrade support, i.e., one can upgrade their
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rolling upgrade -> Is it applicable for both client and server?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not for client.

server version without stopping the application I/O, so we recommend migrating
to higher version.

git clone ssh://username@review.gluster.org/glusterfs
## Things to pay attention to while backporting a patch.

2. Create and checkout a new branch for your work, based on the branch
for the backport version
If your patch meets the criteria above, or you are a user, who prefer to have a
fix backported, because your current setup is facing issues, below are the
steps you need to take care to submit a patch on release branch.

git checkout -t -b bug-123456/release-3.8 origin/release-3.8
* The patch should have same 'Change-Id'.
* The bugzilla ID should be for the same release branch.

3. Cherry pick the change from the master branch.

$ git cherry-pick -x a0b1c2d3e4f5
- verify that the change has been merged into the master branch.
### How to contact release owners?

4. Update/correct the commit message.
All release owners are part of 'gluster-devel@gluster.org' mailing list.
Please write your expectation from next release there, so we can take that
to consideration while making the release.

$ git commit -s --amend --date="$(date)"
[This is one example](https://github.com/gluster/glusterfs/commit/40407afb529f6e5fa2f79e9778c2f527122d75eb) of the commit message that has a good description for a backport. Notice the indention of the patch-metadata like BUG, Change-ID and Reviewed-on tags. There is also the original commit-id that was cherry-picked from the master branch.
-make sure to quote the review tags
-update the BUG reference, point to the BUG that is used for this
particular release-branch
-add a Signed-off-by tag

5. Run `./rfc.sh` to post the backport for review.

./rfc.sh

## via Gerrit web interface
1. Navigate to the required change in Gerrit from any web browser.

2. Click on 'Cherry Pick' button. You will now be presented with a dialogue box with two editable fields. First
one is to specify the branch to which this particular change needs to be
cherry-picked and second one for modifying the already existing commit message.

3. Start entering the branch name in the corresponding field and you can select
the required branch from the list of available branches.

4. Make sure that you only edit the following from the commit message:

* BUG: Replace with the correct bug-id reported against the branch to which change is going to be backported.
* Prefix all other lines except the commit message, Signed-off-by, cherry-picked and Change-Id lines with a greater than symbol and a whitespace '> ' and re-arrange as a whole to have the following format:

<commit message>
. . .
</commit message>

> Reviewed-on: http://review.gluster.org/<change-number>
> Smoke: Gluster Build System <jenkins@build.gluster.com>
> CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
> Reviewed-by: username1 <user1@example.com>
> Reviewed-by: username2 <user2@domain.com>
> Reviewed-by: username3 <user3@abcd.com>

(cherry picked from commit <hash-key>)

Change-Id: <change-id>
BUG: <bug-id>
Signed-off-by: username <user@example.com>

5. Click on 'Cherry Pick Change'. You will now be re-directed to the new change URL.

6. Click on the edit button adjacent to the field named 'Topic'.

7. Add the following as 'Topic':

bug-<bug-id>
Note:- Replace <bug-id> with the required bug-id for that branch.

8. Click on 'Update' or 'Submit'.

After submitting the patch(es), make sure to move the bug to the *POST*
status.
193 changes: 0 additions & 193 deletions Developer-guide/Backport-Wishlist.md

This file was deleted.

5 changes: 1 addition & 4 deletions Developer-guide/Building-GlusterFS.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ The following packages are required for building GlusterFS,
The following dnf command installs all the build requirements for
Fedora,

# dnf install automake autoconf libtool flex bison openssl-devel libxml2-devel python-devel libaio-devel libibverbs-devel librdmacm-devel readline-devel lvm2-devel glib2-devel userspace-rcu-devel libcmocka-devel libacl-devel sqlite-devel fuse-devel redhat-rpm-config
# dnf install automake autoconf libtool flex bison openssl-devel libxml2-devel python-devel libaio-devel libibverbs-devel librdmacm-devel readline-devel lvm2-devel glib2-devel userspace-rcu-devel libcmocka-devel libacl-devel sqlite-devel fuse-devel redhat-rpm-config rpcgen libtirpc-devel make

### Ubuntu

Expand Down Expand Up @@ -169,6 +169,3 @@ steps to build RPMs,
This will create rpms from the source in 'extras/LinuxRPM'. *(Note: You
will need to install the rpmbuild requirements including rpmbuild and
mock)*

A more detailed description for building RPMs can be found at
[CompilingRPMS](./Compiling-RPMS.md).
Loading