[Koha-devel] 3.2.x Release Maintenance Procedures

Chris Nighswonger cnighswonger at foundations.edu
Wed Nov 10 22:30:34 CET 2010


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


More information about the Koha-devel mailing list