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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
