Integration of PTFS code into mainline Koha

I just sent an email to the koha-devel list, outlining my plan for integrating the code in PTFS’ public repository into mainline Koha. With the eye to it being included in the 3.4 release.

Hi All

I'm sure most of you are aware that on May 10 (us time), PTFS made a
whole pile of their hitherto private changes public in the form of a
public git repo.

Galen (as Release Manager for 3.2) has gone through them and marked
the ones that are able to be included in 3.2 and in fact in the last
day we have integrated most of those. But since we are well inside
feature freeze, the new features need to wait for 3.4 (along with
everyone else's new features).

So it becomes part of my responsibility (as RM for 3.4) to work on the
integration of them, new features from everyone else, and to make sure
the work on things like C4::Search, C4::Languages, DBIx::Class, etc
which are slated for 3.4 doesn't get lost.

To that end, we have a wiki page
http://wiki.koha-community.org/wiki/PTFS_Harley_Integration where we
will be tracking integration. What my plan is, is to get each of the
features isolated into a branch based off master. Then QA (Colin) can
look at them and make any recommendations needed. Once they pass QA,
then I will apply the usual RM rules: does this feature or bugfix
cause any regressions, does it change the default behaviour in
unexpected ways, and so on. Then if problems are found they can be
fixed and the code resubmitted for inclusion.

Just to reiterate, there is no special treatment involved here, the
same rules that apply for every other developer apply, what makes this
different is that there are just a big pile of commits to work through
at one time.

Here is a feature branch  that I have created  by cherry-picking the
relevant code from the ptfs/Bug3469 branch.
http://git.koha-community.org/gitweb/?p=koha.git;a=shortlog;h=refs/heads/new_features_ptfs_lost_cards

I'm hoping that PTFS can help creating these branches, but anyone can
do so at let me know where to pull from. They need to have the changes
isolated if possible and be based on new_features. (Which at the
moment tracks master). The faster we can get these feature branches
created, the sooner we will be able to step through the next parts of
integration.
If there are dependencies - and I have been warned granular
permissions is a prerequisite for a lot of the new features - this
should be noted clearly on the wiki page.

If we have the features isolated as much as possible, then they can be
integrated independently, which would mean that one features' failure
to meet the test for inclusion would not stop all the others being
included. So this is our first step. It also allows people to merge
that feature and test it only.

Looking forward to having many of you helping create these branches :)

Chris Cormack
RM Koha 3.4