Why are you rebasing the harley code into 3.2? It was my understanding that PTFS knew it was too late for the code in harley to be included in 3.2
If Harley contains a bug-fix for an problem in 3.2 it's logical to try, if possible, to port the change over. Anyway, since Galen and Chris are two of the smartest guys I know I think I trust them to know what they're doing.
Also, I believe that code will be released more frequently from PTFS than every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first.
Why limit testing to customers for any amount of time except to exclude the rest of the world from having access to it as well? Why pass up the chance to get help from other developers and users in testing new code? Why keep the rest of the world in the dark about what developments are coming down the road so that others aren't working on fixes for the same bugs?
What is Harley if it is not a branch?
I might be possible to consider Harley a branch of 3.0.2 or some variant, but the fact that it includes so many changes, made over so much time makes it impossible to consider it a branch in the sense used by developers who are closely collaborating. Here's how I use branches, based on the advice I've received from my fellow developers. For each bug fix or feature I create a new branch from the very latest version of Koha available in our version-control system. For instance, here's a selection of my current working branches: ip-canbookberenewed-2010-02-05 ip-opac-holds-messages-2010-05-10 ip-transferstoreceive-2010-02-17 master ps-Bug-2981-alternate-solution-2010-05-18 ps-Bug-3459-topissues-2010-06-29 ps-Bug-3721-Lists-missing-2010-06-28 When I first sit down to work I create a branch with a prefix "ip-" for "in progress," give it a short title and bug number if I have one, and add the date I started working on it. Once I have finished my work and submitted a patch I rename the branch with "ps-" for "patch sent" and keep the branch until my patch is approved (fingers-crossed). All this is on my computer in a virtual machine, so in my case I'm not being open as I might. If I had the resources to work on a real server, or if I kept my work on a service like GitHub I could share all these branches with everyone, from the time I first started working on it to the time my patch was submitted. If some time has passed and I see that my patch from one of my "patch sent" branches hasn't been approved I'll switch to that branch and rebase: I'll tell git, the version control system, to grab the most recent Koha commits and merge them with the changes in my patch. If not too much time has passed, or the files I changed haven't been worked on by others the rebase will be successful and I'll know I'm still on track. If not I might have to manually make changes to my original commit so that it fits in again with the work others have been doing. I can't submit a patch and expect it to automatically work a month from now, a week from now, or even a day from now. I'm responsible for keeping up. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org