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.
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.
- No feature from master would be backported to the release branch
- CVE ie., security vulnerability (listed on the CVE database) 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 server version without stopping the application I/O, so we recommend migrating to higher version.
Things to pay attention to while backporting a patch.
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.
- The patch should have same 'Change-Id'.
- The bugzilla ID should be for the same release branch.
How to contact release owners?
All release owners are part of 'email@example.com' mailing list. Please write your expectation from next release there, so we can take that to consideration while making the release.