About an hour ago I cut a beta for Koha 3.12.0. The tarball is available at http://download.koha-community.org/koha-3.12.00-beta1.tar.gz and the release notes at http://git.koha-community.org/gitweb/?p=koha.git;a=blob_plain;f=misc/release_notes/release_notes_3_12_0.txt;h=0e8a3cf74de202af325069b7aec329eff229ec11;hb=a4f4d69c3b0f82e765b20cdee7be95456ee9db23
Packages will follow in the squeeze-dev repository sometime at the beginning of the week.
As a reminder, Koha 3.12 is in feature freeze so any features that are not in the beta will not be in Koha 3.12, and I will not respond to any complaints about features that didn’t make the cut-off other than forwarding them to the Koha mailing lists.
So, what now? Now, we seek out and destroy bugs! If you have a spare testing server, take the beta for a spin, and try to break it. “Sure,” you say, “I know that I can do that. But what can I help with that deserved an exclamation mark in the subject line?” I’m glad you asked. Here is a list of some things that need to be done before May 22:
* Koha has to be translated.
I will be asking the Translation Manager to pull the latest strings into Pootle so that the translation teams can get a head start (and if you know any language other than American English, you can help translate! Head on over to http://translate.koha-community.org/
and get started)
* Koha’s documentation has to be updated.
* Koha’s installation instructions need to be updated.
Some of the installation instructions that are included in the tarball were last updated (for all practical purposes) in 2010. That’s a long time ago in computer time. If you have some thoughts on how the various INSTALL.* files in the tarball might be updated to be more clear, open up a text editor and send in your corrections (preferably as a patch, but if you have suggestions and are not comfortable with git, an e-mail to koha-devel will work too).
* Enhancement bugs need to be reclassified.
During the 3.12 release cycle we added a new category of bug report: “New feature.” However, a lot of the new features that are going into 3.12 are still listed as “enhancements” in Bugzilla, which means the automated release notes generator doesn’t pick them up properly. Any time the RM spends fixing that is time the RM does not spend fixing problems with Koha. This is is a task that anyone can do. All it takes is a bit of critical thinking and an account on Bugzilla: http://bugs.koha-community.org/bugzilla3/
* Open bug reports need to be (re)confirmed.
We have scads of bug reports in Bugzilla, and many of them probably report bugs that have been fixed for weeks, months, or years. If we can get all the bugs that are already fixed closed, it’ll be easier to focus on the bugs that still exist. Head on over to Bugzilla, choose some old bugs, and start testing!
* Bugs need to be fixed.
This goes hand-in-hand with the testing that you’ve all heard me to talk to death, but once a bug has been found, it has to be fixed. If you know how to fix a bug, please do!
* Bug fixes need to be tested.
There are many bugfixes already on bugzilla, and there will be many more being written in the next two months. After a patch has been written, it has to be tested by at least one third party (i.e. not the developer and not me) in order to move through the QA process to inclusion in Koha. Even if you don’t have a spare server, you can test patches in the sandboxes hosted by BibLibre: http://wiki.koha-community.org/wiki/Sandboxes
* Volunteers must be found, recruited, and/or made for 3.14.