During the general IRC meeting today, a question came up concerning how I plan to push patches to 3.2.x. Here is the general procedure I intend to follow, but am certainly reserving my right to change it as necessary. 1. The general policy will be to cherry-pick/merge patches from HEAD as they appear and are applicable to 3.2.x. Besides the fact that bugs in 3.2.x are also bugs in HEAD, these patches have already passed QA and are considered stable, so this greatly reduces the workload. 2. At such a time as a merge conflict should occur due to the eventually inevitable divergence of 3.2.x and HEAD, *the submitter* of a patch will be responsible to ensure that the patch applies to both branches (HEAD and 3.2.x) *before* submission, and if the patch does not apply to the 3.2.x branch, *the submitter* will be responsible to take whatever action is necessary to make it apply before submission. This will most likely mean submitting two versions of the patch: one for HEAD and one for 3.2.x. This responsibility is an ethical one as it is not ethical to expect the release maintainer who is one person to make the many patches apply when the submitter who is one person merely has to make one patch apply. One thing which will greatly reduce the burden of #2 is the RM's planned use of topic branches. Merge conflicts are much easier to manage and far less overwhelming with the use of topic branches. Suggestions and opinions are welcome. Kind Regards, Chris Nighswonger Koha 3.2 Release Maintainer