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

Centralize and move to gitlab
by Jonathan Druart 08 Aug '18

08 Aug '18

Hi devs, (Spoiler: I am not talking about a move from bugzilla to gitlab for the Koha git repo) Just a quick comment: gitlab has the ability to move projects with all the issues. >From the export page of a project, they say: """ The following items will be exported: Project and wiki repositories Project uploads Project configuration including web hooks and services Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities """ So that will be easy to move (already discussed with Chris, will do in May) * koha-community-devs-users/kohadocs to koha-community/kohadocs * https://gitlab.com/koha-dashboard/koha-dashboard to koha-community/koha-dashboard And the ones from github too: * joubu/koha-misc4dev to koha-community/koha-misc4dev * Koha-Community/qa-test-tools to koha-community/qa-test-tools Then, maybe: koha-testing-docker koha-release-notes kohadevbox koha-howto The idea is to centralize our things in one place, ease the PRs and the ability to clone/fork keeping the visibility on what is the reference (account 'koha-community'). I would also like to generate a CI configuration for some of them. CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146 (I am going to submit that on bugzilla soon) CI file for the manual: https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-c… Any pros/cons? Cheers, Jonathan (No troll please)

11 16

Koha Community Newsletter: July 2018
by Koha Newsletter 02 Aug '18

02 Aug '18

The Koha Community Newsletter for July 2018 is here: https://koha-community.org/koha-community-newsletter-july-2018/ 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. PS: please excuse the delay -- we had a baby the 20th of this month! Healthy baby girl. Thanks!

1 0

Batch cleanup to the catalog
by Cab Vinton 01 Aug '18

01 Aug '18

Hi, All -- Koha's Batch Record Modification (BRM) tool makes it very easy to make large-scale changes to the catalog. And we know that many catalogers like to have their records just so :-) Is there a cost in overhead, however, to making such changes? For example, if a catalog of 150,000 records contains 75,000 unwanted MARC fields, would you delete them, even if they're not displayed in the OPAC or otherwise interfering w/ functionality? In particular, I'm wondering whether using the BRM tool involves the creation of new data so that there's no real net gain w/ respect to the goal of having a "cleaner" database. (In our case, we've turned off the CataloguingLog system preference.) Along the same lines, are there any advantages to doing large-scale batch process via the backend instead, i.e., as opposed to w/ the built-in staff tools such as BRM? (I'm assuming there's no issue w/ using such tools to work w/ much smaller subsets of records.) Thanks in advance for any guidance. All best, Cab Vinton, Director Plaistow Public Library Plaistow, NH

2 2