[Koha] Koha releases - Clarification/correction

[Owen Leonard]

> 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