Hello koha-devel, I just updated the 3.8 release process with the schedule/planning of the release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8 Here it is: March, 23th (1 month before the release) = feature freeze. April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0 IMPORTANT = perltidy process In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code. Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code. Pro: * the code will be perltidied, the coding guideline will be applicable * all perltidy being made at the same time, it will be easier to read the git log. (One of the argument against perltidying is that it's a problem for reading git history) * doing that for a release is better for future bugfixes means that patches will apply on 3.8 as well as on master. Cons: * patches that are waiting may become "does not apply" because of the perltidy thing * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that will add more work for 3.6 releases. All in one, our conclusion was that the best solution is to do that during a release process. So I plan do it during 3.8 release. (I have a (small ?) question about that : do you think I should make only one huge commit with perltidy ? one for each directory ? one for each file ?) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08