[Koha-devel] Koha 3.8 release schedule & perltidy process

[Marcel de Rooy]

Hi Paul,
What is the exact procedure? All patches submitted before March 23 or signed-off before March 23 are candidates for the 3.8 release?  If so, how do we separate them easily from the patches submitted later? What is strong feature freeze exactly here? 

About the commits: I would suggest to put multiple files in a perltidy commit, not per file.

Marcel

-----Oorspronkelijk bericht-----
Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain
Verzonden: donderdag 8 maart 2012 13:59
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] Koha 3.8 release schedule & perltidy process

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 _______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/