This document is built on the information provided by Thomas Berezansky on the Evergreen wiki. I just tried to make it more user friendly to someone like me. It describes some of the components of Evergreen such as OpenSRF (including the specific Perl modules used), PostgreSQL (including a description of each schema), Fieldmapper IDL, and the OPAC and staff client.
Tom's original work is here: http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview
The Solano Napa and Partners (SNAP) Consortium have developed a functional requirements document that is available for you to use in your next ILS procurement. The work was funded by an LSTA grant.
SNAP and library staff worked with Melissa Stockton (Quipu Group) and Lori Bowen Ayre (The Galecia Group) to develop the document through a series of focus groups that tackled the various functional areas of an ILS.
The document is designed for a consortium but could be fairly easily modified for use by stand-alone libraries.
An Open Doc version of SNAP's Requirements is attached to this post in case anyone would like to use it in their own procurement or ILS evaluation.
Owen Leonard provided a succinct and useful description of how new developments make their way into a final release. Here's my rendition of the process....
He began the story with "a patch is submitted" which means that your or your developer has figured out how to add the enhancement or fix the bug and the code has been made available to other developers to take a look at. That code is "a patch."
Once the patch is available to others, it can be pulled into a live or (more likely) a test system so someone can test it. Once someone tests it and verifies that that is indeed a useful and functional patch, they can "sign off" on that patch. It is great to have more than one person "sign off" on a patch. The patch cannot move to the next step until at least one person has signed off and changed the status of the patch to (predictably) "Signed Off."
After that, it is really up to the core development team to take the necessary steps to get that patch into the next release.
The QA manager (currently that person is Ian Walls, congratulations, Ian!) tests the "signed off" patch again and confirms that it works AND that the code meets project standards. Only the QA Manager can get it past this step. Once it is approved, its status become "Passed QA."
Next, the Release Manager examines the patches that have "Passed QA" and assuming the RM also agrees that the patch is good, that patch is "pushed" which means it becomes part of the next release!
This post is copied from the Koha Mailing list. It is the fabulous Ian Wall's response to a question someone had about what is involved in hosting one's own Koha server...
To host your own server, you'll need some level of comfort with Linux command line operations. I recommend a Debian Squeeze server. You can either purchase a new physical machine, or create a virtual server on an existing machine or in the cloud. You can quickly fire up a server in the cloud using services like Amazon Web Computing, Rackspace or Linode. This saves you from having to install an operating system on a piece of physical or virtual hardware.
Once you've got the server up and running, you'll need to install Koha. You can do so from the packages, from the git repository or from the downloadable tarballs. Personally, I recommend the git installation, but my understanding is that the packages are a little more user-friendly at the installation phase. Are you going to be developing on Koha at all? If so, then a git installation is definitely the way to go, so you can track your local changes, and format them in a way to submit back to Koha!
In addition to installing Koha itself, you'll need to install it's dependencies. That includes MySQL (with which you said you were familiar), Zebra and Apache (Perl is almost always installed by default). The installation instructions for Koha will walk you through those steps. Further, if you want your Koha install to be able to send email notices, you'll want to install and configure an MTA (Message Transfer Agent). I recommend Postfix, but exim4 also works. The default SendMail also works, but I've found it a bit less flexible and thus a little more frustrating.
You'll also need to be comfortable with the crontab, so you can set up nightly jobs like fines, overdue notices, and backups. This is one part syntax (knowing how to put an entry on crontab) and one part text editor familiarity (vi or nano, typically).
If all this seems a bit overwhelming, you're not alone. If you need assistance, I'm sure there are Koha support companies in your geographic region who would be happy to assist you with installation, and may even provide hosting options. Check http://koha-community.org/support/paid-support/ for a listing of known support companies from all over the world.
This just in via the Evergreen Mailling list (http://open-ils.org/listserv.php):
The Sitka team has produced four step-by-step videos on Evergreen Booking. Hosted by Jennifer Pringle, Sitka Trainer, the videos walk through Booking administration and general functionality for staff.
The videos are licensed CC-BY-SA 3.0 and are available here:
http://videos.cooperative.bclibraries.ca/
And there's more! The Sitka team has also produced several videos about Reports and they are planning to do a series on Acquisitions! Stay tuned.
