[Gluster-devel] Reminder on posting patches for stable (3.4.x and 3.5.x) releases

Niels de Vos ndevos at redhat.com
Wed Jun 25 09:05:05 UTC 2014


Hi all,

while trying to get 3.5.1 released, I've noticed some difficulties and 
inconsistencies on how patches for the stable 3.5.x release get posted.  
Unfortunately I had to reject some last minute requests to include some 
changes that were not trivial. Some of these patches were waiting 
a while already, and just got missed in the process. In order to prevent 
this kind of disappointments in future, I'd like to ask you guys to pay 
attention to these points:

1. It is advisable to have separate bugs filed for each branch that 
   needs the change(s). Each bug can then be used to track the status of 
   the patch. It can be acceptable to send the patch for the master 
   branch and *one* stable release branch. See the Backport Wishlist on 
   how to mark bugs/changes for inclusion in stable releases:
   - http://www.gluster.org/community/documentation/index.php/Backport_Wishlist

2. A patch for a stable branch should have been reviewed and merged in 
   the master branch. If the patch is not needed in the master branch, 
   explain in the commit message why that is.

3. Backports of patches should normally have the same Change-ID as the 
   patch in the master branch. In case the patch differs a lot, you 
   should explain the needed differences in the commit message.

4. In the commit message of the backport, include the link to the review 
   of the patch in the master branch. Possible also mention the 
   commit-id of the patch in the master branch, this makes it easier to 
   compare changes with git directly (Gerrit is sometimes slow).

5. It helps if others have reviewed your backport. Ask the reviewers who 
   checked the change for the master branch to review the backport too.  
   Release maintainers will review the change as well, but having an 
   additional pair of eyes checking for issues is very welcome.


The above are just some of the things that I can think of immediately.  
We have started to document the procedure for doing backports on the 
wiki, and may include the points from this email(-thread) in there too:
- http://www.gluster.org/community/documentation/index.php/Backport_Guidelines

If you have any questions, or would like to check if a bug/change will 
be included in a next stable release, feel free to contact the 
maintainers (this mailinglist, in #gluster-dev on freenode or if needed 
through private email).

Thanks,
Niels


More information about the Gluster-devel mailing list