- Koha-devel - lists.koha-community.org

Hi
by Ramesh Parichi 08 Sep '15

08 Sep '15

Hi Friends Can I have the step by step procedure to install KOHA on Ubuntu 14.04 LTS. I have old procedure and i believe there is some change in the procedure in 14.04. please help me out. Regards P. Ramesh Senior Technical Officer Osmania University Hyderabad, India.

2 1

koha for e-resource management
by long_sam.tw 08 Sep '15

08 Sep '15

Dear koha folks. Recently , many ILS provide e-resource management for library. In koha, Are there some plan about e-resource management in the future? BR, longsam

3 5

Atomicupdates for clunky forked Kohas
by Kivilahti Olli-Antti 04 Sep '15

04 Sep '15

Hi there! I heard the community is moving to atomicupdates. We moved to atomicupdates as well! To help us better manage atomicupdates, I devised a installer to keep track of which atomicupdates have already been applied so we don't apply the same updates many times. Also when we deploy/backport more and more feature, it becomes really hard to know which atomicupdates have been installed and which have not. Check this Bug out if you are putting features in production before they get to master. There is also a nice slide show! http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14698 Here is the --help from atomicupdates.pl, it introduces itself quite nicely! <<SNIP atomicupdates.pl Runs all the not-yet-applied atomicupdate-scripts and sql in the atomicupdates-directory, in the order specified by the _updateorder-file. This script uses koha.atomicupdates-table to see if the update has already been applied. Also acts as a gateway to CRUD the koha.atomicupdates-table. -v --verbose Integer, 1 is not so verbose, 3 is maximally verbose. -h --help Flag, This nice help! -a --apply Flag, Apply all the pending atomicupdates from the atomicupdates-directory. -d --directory Path, From which directory to look for atomicupdate-scripts. Defaults to '$KOHA_PATH/installer/data/mysql/atomicupdate/' -r --remove String, Remove the upgrade entry from koha.atomicupdates eg. --remove "Bug71337" -i --insert Path, Add an upgrade log entry for the given atomicupdate-file. Useful to revert an accidental --remove -operation or for testing. eg. -i installer/data/mysql/atomicupdate/Bug5453-Example.pl -l --list Flag, List all entries in the koha.atomicupdates-table. This typically means all applied atomicupdates. -p --pending Flag, List all pending atomicupdates from the atomicupdates-directory. -g --git Path, Build the update order from the Git repository given, or default to the Git repository in $KOHA_PATH. Eg. --git 1, to build with default values, or --git /tmp/kohaclone/ to look for another repository EXAMPLES: atomicupdate.pl -g 1 -a Looks for the Git repository in $KOHA_PATH, parses the issue/commit identifiers from the top 10000 commits and generates the _updateorder-file to tell in which order the atomicupdates-scripts are executed. Then applies all pending atomicupdate-scripts in the order (oldest to newest) presented in the Git repository. atomicupdate --apply -d /home/koha/kohaclone/installer/data/mysql/atomicupdate/ Applies all pending atomicupdate-scripts from the given directory. If the file '_updateorder' is not present, it must be first generated, for example with the --git 1 argument. UPDATEORDER: When deploying more than one atomicupdate, it is imperative to know in which order the updates are applied. Atomicupdates can easily depend on each other and fail in very strange and hard-to-debug -ways if the prerequisite modifications are not in effect. The correct update order is defined in the atomicupdates/_updateorder-file. This is a simple list of issue/commit identifiers, eg. Bug5454 Bug12432 Bug3218 #45 This file is most easily generated directly from the original Git repository, since the order in which the Commits have been introduced most definetely is the order they should be applied. When deploying the atomicupdates to production environments without the Git repository, the _updateorder file must be copied along the atomicupdate-scripts. P.S. Remember to put atomicupdate/_updateorder to your .gitignore SNAP>> -- Olli-Antti Kivilahti Järjestelmäkeittäjä vaarakirjastot.fi +358 50 449 7763 --Powered by Kubuntu Linux!

1 0

3.14 EOL and 3.22 Release Maintainer
by Fridolin SOMERS 02 Sep '15

02 Sep '15

Hie there, I think time has come to declare the end of maintaining the 3.14.x. I'll provide a last version in octobre, so if you want something in it, feel free to contact me. It whas a really good exepience for me, I'd like to candidate as Release Maintainer for 3.22. Best regards. -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 0

Re: [Koha-devel] Thoughts about timing and Koha schedules
by Kathryn Tyree 02 Sep '15

02 Sep '15

Hi Brendan and all, I'll note the Catalyst perspective/experience on this. The financial year/deadlines in NZ are also July-June or Jan-Dec. The only time of year that is 'typically' quieter for us as a company is Mid Dec-Mid Jan while many of our customer libraries are closed. We take holidays, and catch up on upgrades for any libraries who like to test while their office is quiet. We wouldn't expect to be able to commit any more time to community efforts by changing the release dates. At present we have three people with community roles/monthly responsibilities, and everyone puts time into testing/patching when other work is quiet no matter what the time of year. If something urgent like security vulnerabilities are found, everyone who is needed in the patching effort drops everything else until those are fixed. It feels a bit like trying to find a time of day when everyone can come to a community meeting - it'll never happen! Therefore I think the most important thing is that the dates are fixed. I'd agree its something to put to the main list/everyone. Cheers, Kathryn Kathryn Tyree http://catalyst.net.nz/ Message: Date: Fri, 21 Aug 2015 01:56:45 -0700 From: Brendan Gallagher <info(a)bywatersolutions.com> To: Koha Devel <koha-devel(a)lists.koha-community.org> Subject: [Koha-devel] Thoughts about timing and Koha schedules Message-ID: <CANGWTFRMD2Jp2_Lqsr4bf=G0Rs6ywA7WjWNqUO2tJBiMkvZycA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi All - ByWater is on its 7th year, so we have a solid set of data for analyzing, and recently I've noticed a few things. Let me try and paint the picture. Major Koha releases are every six months and usually the 22nd day of the month, with the target being November and May. (Please correct me if I am wrong) Library funding cycles in the US run either fiscal year (July to June), Calendar year (January to December), or some odd fiscal year close to the July~June year. Ok that being said from the time management situation with ByWater that introduces a few complexities. (Let me describe the workflow and maybe you'll see what I am talking about) Most of the time a library will sign a migration contract with us that dictates we must have them "go-live" before a certain fiscal date OR the library isn't really able to "sign" a contract for services until a certain fiscally motivated date (which places us into a similar roll-out). That being said we find that May and November (plus and minus a month) are our busiest times of the year. I've got 3 people on the road for education/training, 3 people heavily in the fields of migrations scripts, and 3 developers that are heavily in the field of meeting development expectations for lots and lots of go-lives (*note - plus additional staff to support an influx in tickets or other support needs during a go-live period). So if we slide the releases to say February and August - I would be able to dedicate more man power (9+ people from the above paragraph) around the heavy testing/ debugging / bug writing/squashing periods for a release. I know I know - there isn't really a time that Koha doesn't need more testing, but I've noticed that the volunteer effort is usually much greater/demanding the closer we are to major release date. I am wondering if others are finding the same with their work schedules (other support providers, academic institutions, public institutions, and my favorite volunteers). Are there certain times of the years where your day job is predictably busy that you aren't able to dedicate the resources that you want towards the greatest project in the world Koha. With the data set that we're sitting on here, we are constantly seeking ways that we can contribute more. Just a thought and was curious if others analyzed a similar aspect with their environment and perhaps maybe we should bring such a discussion into the open or a general IRC meeting. Especially any of us that are support providers we should be always be thinking about how we can do more for Koha. Thanks and Cheers (another sleepless night thinking about my favorite subject - Koha), Brendan

1 0

Test Planck
by Tajoli Zeno 01 Sep '15

01 Sep '15

Hi to all, one important thing to do is to test in master the new code for plack. But, after install planck, how could I test error connect with plack ? Do you have any suggesstion about this topic ? Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli(a)cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

2 1

Facilitate integration of some patches
by Jonathan Druart 01 Sep '15

01 Sep '15

Hello devs, I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low. Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem. So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step. I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea. Cheers, Jonathan PS: If I am correct, we already have discussed about that previously.

9 10

Koha 3.16.14 released
by Mason James 31 Aug '15

31 Aug '15

The Koha release team are proud to announce the release of Koha 3.16.14. This release contains 9 bugfixes, including 1 critical bug. All 3.16.x series users are strongly encouraged to upgrade to this version. Please install from the tarball, as .deb packages are not currently built for the 'oldoldstable' series More installation info... http://www.koha-community.org/download-koha The full release notes are at... http://koha-community.org/koha-3-16-14-released Mason

1 0

Global Bug Squashing Day - September 3 2015!
by Katrin Fischer 31 Aug '15

31 Aug '15

Hi all, we have a Global Bug Squashing Days (GBSD) planned for September 3 2015! During the July General IRC meeting [1] we talked about the Global Bug Squashing Days (GBSD) in general and about how to make them more successful. One of the ideas discussed was to have some events during the day - tutorials, questions & answers, developers talking about new stuff they are working on etc. So now we are looking for: Ideas! - What would you get interested in participating? - What would help you to get started with testing? - Do you want to know how to file a bug? - Sign off a patch? - How to use a sandbox? - How to set up a Koha testing environment`on your own computer? ... Volunteers! - Would you be able to run a tutorial on that day? - Do you want to present some of your new developments? - Will you be there to answer questions during a specific time slot? ... Please let us know and/or add your ideas to the wiki page [2]! Thanks, Katrin [1] http://wiki.koha-community.org/wiki/General_IRC_meeting_8_July_2015 [2] http://wiki.koha-community.org/wiki/2015-09-03_Global_bug_squashing_day

1 1

Koha Community Newsletter: August 2015
by kohanews 28 Aug '15

28 Aug '15

Fellow Koha users: The Koha Community Newsletter for August 2015 is here: http://koha-community.org/koha-community-newsletter-august-2015/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! Chad Roseburg Editor, Koha Community Newsletter

1 0