A new request with request id 13989 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :

Title : Koha-devel Digest, Vol 193, Issue 5
Category :
Description :
Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Re: My dev list for 22.05 (Marcel de Rooy)
2. Re: My dev list for 22.05 (Paul Poulain)


----------------------------------------------------------------------

Message: 1
Date: Fri, 3 Dec 2021 09:43:29 +0100
From: Marcel de Rooy <rooy.de.m@gmail.com>
To: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Cc: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID:
    <CAGv4ghYnfwCtDdf-U3+5qsk3Kq25LLBOg5H=ncVAgkXC_j=K=g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

A first reply on the points you mention. I would like to add a few on my
second reply ;)

> 2. Remove item-level_itype
I agree. Happy to support that one.

> 3. Merge biblio and biblioitem
I understand that you want that. But just feeling that it might be harder
to swallow..

The other points are surely interesting.

Op wo 1 dec. 2021 om 16:24 schreef Jonathan Druart <
jonathan.druart@bugs.koha-community.org>:

> Hello everybody,
>
> I have been listing some tasks I would like to work on during the next
> development cycle.
> I suggest a give and take approach. Help me on one or more of those
> topics and I will help you as I can on whichever topic(s) you decide.
>
> 1. Add more sample data to misc4dev
> It can be sometimes painful to recreate some situations when using the
> data provided by misc4dev. I would like to extend the data set to make
> some patches easier to test out of the box.
> We could, for instance, have:
> - big records
> - records with many items
> - records and items with cover images
> - more acquisition data
> - etc?
>
> Just tell me what kind of data you miss on a regular basis and I will
> try to add them to misc4dev. If you have such records/data, send them
> to me for inclusion!
>
> 2. Remove item-level_itype
> We have been discussing this one for a long time already, is it the
> time to tackle it down?
> See
> -
> https://lists.koha-community.org/pipermail/koha-devel/2015-December/042114.html
> - Bug 10385 - item-level_itypes checks need to be refactored
> - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype
>
> The work would consist in providing a plan to go ahead then provide a
> patch.
>
> 3. Merge biblio and biblioitem
> Self-explanatory, merge the 2 tables to remove the unneeded 1-1
> relation between them
>
> 4. Improve action logs
> We have had several changes and reports in this area lately. We could
> improve the way we log changes for easy tracking and comparaison.
> See
> - Bug 28714 - Bib record change tracking action log
> - Bug 29451 - Merging records and authorities - log details for the
> delete action so it could be recreated
> - Bug 28692 - Reduce DB action_log table size
>
> I think we should add 2 new columns to log before and after the object
> is updated, serialized in JSON. We could then generate the diff on
> display.
>
> 5. Patron searches (holds and checkouts)
> Those two patron searches do not use the same code as the other patron
> searches.
> We should uniformize them.
> - Bug 29136 - Patron search on request.pl has performance and display
> issues
> - comment 37 of Bug 15812 - Checkout search with too many results
> (single character search) causes poor performance or timeout
> There is also bug 29125 (Use Koha::Patron object in
> C4:Utils::DataTables::Members.pm) that is removing the SQL query to
> use Koha::Patrons.
>
> 5. Async ES indexation
> Now that we have the task queue we should use it to index the records
> and don't index them in a synchronous way.
> Bug 27344 - Implement Elastic's update_index_background using
> Koha::BackgroundJob
> If we don't want to use the task queue for that purpose we should
> provide another solution.
> To be discussed and implemented (or validate and test the patches that
> are already on bug 27344)
>
> 6. mailman2discourse
> It seems that people are willing to move from our historical mailing
> list to something more modern like discourse.
> I would like to get back to this job, who is willing to help me?
>
> 7. Split and shrink git repo
> I've already done several iterations in this area and I would like to
> get back to it. However I need someone with good git knowledge to
> continue and focus on this.
>
> 8. Move C4 and Koha to lib
> We discussed that earlier and I even attached patches to bug 28589. I
> don't think it's top priority but I can dedicate some hours if some of
> you think it is a move we must do now.
>
> 9. Improve our strings for translators
> See
> - Bug 29602 - We must be nicer with translators
> - Bug 20988 - [OMNIBUS] Internationalization: wrap all translatable
> text inside t() calls
> I had to spend some time in the PO when I was releasing 21.11, and
> really we are not nice with translators. The %s everywhere make things
> very hard to maintain, read and translate.
> We should help them, and even if a big move is needed it will be a win
> in the long term, for us (developers) and for them.
>
> There are some other topics I have in mind, but those ones need to be
> done in small teams as they are quite big.
>
> Let me know what you think and if you are willing to give me a hand!
>
> And also, what's on your list for 22.05?
>
> Cheers,
> Jonathan
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211203/df34ad1e/attachment-0001.htm>

------------------------------

Message: 2
Date: Fri, 3 Dec 2021 11:00:36 +0100
From: Paul Poulain <paul.poulain@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID: <de4b1d47-d368-f43b-60e2-3850d331288f@biblibre.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hello all,

Regarding this topic : why not also investigate the new data models that
will replace MARC ?

We store the data in original form (marcxml) and move to
biblio/biblioitems a part of the data that is useful for basic operation
(like getting the title and the author).

We could import different data models with the same mechanism (RDA, DC,
...). The biblio_metadata.format and schema fields were created with
this idea in mind. That would require an additional layer for
transforming format/schema to internal Koha and many more things, it's a
long term goal.

Le 01/12/2021 à 12:55, Jonathan Druart a écrit :
> 3. Merge biblio and biblioitem
> Self-explanatory, merge the 2 tables to remove the unneeded 1-1
> relation between them

--
Paul Poulain, Associé-gérant / co-owner
BibLibre, Services en logiciels libres pour les bibliothèques
BibLibre, Open Source software and services for libraries



------------------------------

Subject: Digest Footer

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/


------------------------------

End of Koha-devel Digest, Vol 193, Issue 5
******************************************


NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.